Hужен ли нам С++?

Thu Sep 29 2005 19:55, Olga Nonova wrote to All:

ON> Осваиваю GNU пакет для M68K и там есть возможность писать на С++. Стала ON> разбираться и выяснила, что из С++ взята возможность обьявления class, но ON> использовать эти обьекты допускается только статически и нельзя ON> передавать ссылки к методам из модуля в модуль. Спрашивается, нафига ON> тогда козе баян?

Я не знаю, зачем вам баян, почтенная Ольга :-)

ON> Как я понимаю, обьектное программирование было создано ON> для динамического размещеия обьектов и для наследования (окна всякие, ON> списки, коллекции...)

Hеправильно понимаете. С++ это такой усовершенствованный C. Для упрощения жизни при написании больших программ и предотвращения некоторых типичных ошибок.

ON> А второй вопрос такой: кто-нибудь из ембеддеров однокристаллок применял ON> динамическое размещение обьектов? Создавал и убирал их из памяти?

Да.

ON> Это и есть основной вопрос- а нужен ли нам С++? Основной вопрос: куда мы сегодня пойдем на ланч. Это вопрос, а все остальное - фигня.

VLV

"Fortress of Madman"

Reply to
Vladimir Vassilevsky
Loading thread data ...

Здравствуйте, Уважаемый All!

Осваиваю GNU пакет для M68K и там есть возможность писать на С++. Стала разбираться и выяснила, что из С++ взята возможность обьявления class, но использовать эти обьекты допускается только статически и нельзя передавать ссылки к методам из модуля в модуль. Спрашивается, нафига тогда козе баян? Как я понимаю, обьектное программирование было создано для динамического размещеия обьектов и для наследования (окна всякие, списки, коллекции...). Зачем ембеддеру могут понадобится классы С++, если от них можно породить только статические обьекты и никакого наследования? А второй вопрос такой: кто-нибудь из ембеддеров однокристаллок применял динамическое размещение обьектов? Создавал и убирал их из памяти? Это и есть основной вопрос- а нужен ли нам С++?

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

Hello Olga.

29 Sep 05 19:55, Olga Nonova wrote to All:

ON> Осваиваю GNU пакет для M68K и там есть возможность писать на С++. ON> Стала pазбиpаться и выяснила, что из С++ взята возможность обьявления ON> class, но использовать эти обьекты допускается только статически и ON> нельзя пеpедавать ссылки к методам из модуля в модуль. Hе совсем понятно, пpимеpы можно? Может быть пpосто не опpеделены функции pаспpеделения памяти? ON> Спpашивается, ON> нафига тогда козе баян? Как я понимаю, обьектное пpогpаммиpование было ON> создано для динамического pазмещеия обьектов и для наследования (окна ON> всякие, списки, коллекции...). А мне кажется, что дело в пеpвичности данных в пpотивовес пеpвичности функций. Опеpделяется не какие данные пеpедаются функциям, а какие методы существуют у объекта. А pазмещение - дело десятое. Ассемблеp тоже может быть объектно-оpиентиpованным :) r1.add(r0); r1.add(#3); Вот тебе и методы и пеpегpузка функций :) ON> Зачем ембеддеpу могут понадобится ON> классы С++, если от них можно поpодить только статические обьекты и ON> никакого наследования? Hапpимеp нестандаpтные типы данных. Скажем, 3-байтные данные и аpифметические опеpации с ними. Или твои любимые паскалевские стpоки. Пpичем с контpолем максимального pазмеpа :) ON> А втоpой вопpос такой: кто-нибудь из ембеддеpов ON> однокpисталлок пpименял динамическое pазмещение обьектов? Если очеpеди или связные списки, то почему бы и нет. ON> Создавал и убиpал их из памяти? Размещение локальных пеpеменных тоже можно считать динамическим в некотоpых случаях в некотоpом смысле :) ON> Это и есть основной вопpос- а нужен ли нам С++? Hе, надо вопpос как-то поостpее поставить. Так уже наpод на флейм не pаскpутить :) Вопpос как пеpвый байт выцаpапать из двух и то больше pеакции вызвал :)

Sergey

Reply to
Sergey Davydov

Hello Olga.

Thu Sep 29 2005 19:55, Olga Nonova wrote to All:

ON> Это и есть основной вопрос - а нужен ли нам С++?

В C++, кроме классов, есть ещё много полезных усовершенствований. Строчные комментарии, объявления const, inline, передача аргументов по ссылке, объявление параметра цикла в заголовке цикла, более строгая проверка синтаксиса... да и классы, если использовать их ограниченно, "инкапсулированно", а не строить деревьев, могут сделать программу понятнее. Вот, например, такой класс кольцевого буфера:

class Ring { public: Ring (); bool Empty (void); bool Full (void); bool Put (byte data); byte Get (void); private: void Inc (byte & Idx); byte Next (byte x); byte Head, Tail; qbuf Buf; };

Ring::Ring () { Head = 0; Tail = 0; }

byte Ring::Next (byte idx) { #if QBUF_SIZE_IS_POWER_OF_TWO return (idx+1) & (QBUF_SIZE-1); #else return (idx+1) % QBUF_SIZE; #endif }

void Ring::Inc (byte & idx) { idx = Next(idx); }

bool Ring::Empty (void) { return (Head == Tail); }

bool Ring::Full (void) { return (Next(Tail) == Head); }

bool Ring::Put (byte data) { if (Full()) return false;

Buf[Tail] = data; Inc(Tail); return true; }

int Ring::Get (void) { int result;

if (Empty()) return -1;

result = Buf[Head]; Inc(Head); return result; }

Dimmy.

Reply to
Dimmy Timchenko

Привет!

"Sergey Davydov" писал к "Olga Nonova"

Не торопись отвечать. В автомобильных эхах типа cars.japan плюсуют тех, кто отвечает на его провокации. Предысторию можно в kitchen посмотреть.

С уважением,

Виталий Насенник

Reply to
Vitaly Nasennik

"Olga Nonova" snipped-for-privacy@starline.ee сообщил/сообщила в новостях следующее: news:dhh2oh$v91$ snipped-for-privacy@www.fido-online.com...

Ссылку к нестатическому методу класса? Хорошо трава в Эстттоонии уродилась! Hу и по существу бредите вы скорее всего. В gcc для AVR таких проблем нет.

Бредите вы, все прекрасно наследуется, даже множественное наследование есть.

Да.

Как связано динамическое размещение объектов и c++? Если нужно постоянно создавать и уничтожать экземпляры классов, тогда уж о джаве можно думать, там для этого как-то лучше приспособлено, ну и ряд других приятностей есть.

Денис.

Reply to
Dennis Opanasenko

Здравствуйте, Уважаемый Dennis!

Fri Sep 30 2005 12:31, Dennis Opanasenko wrote to All:

DO> Как связано динамическое размещение объектов и c++? Если нужно постоянно DO> создавать и уничтожать экземпляры классов, тогда уж о джаве можно думать, DO> там для этого как-то лучше приспособлено, ну и ряд других приятностей DO> есть.

Про Java- это само собой. И все же меня интересует: разве С++ отличается от просто С не возможностью обьектного программирования? Причем достоинства такого программирования по-настоящему расскрываются в условиях, когда "нужно постоянно создавать и уничтожать экземпляры классов"?

Всего Вам Хорошего Ольга

Reply to
Olga Nonova

Hello Dimmy.

30 Sep 05 06:48, you wrote to Olga Nonova:

DT> В C++, кроме классов, есть ещё много полезных усовершенствований. DT> Строчные комментарии, объявления const, inline, передача аргументов по DT> ссылке, объявление параметра цикла в заголовке цикла, более строгая DT> проверка синтаксиса... да и классы, если использовать их ограниченно, DT> "инкапсулированно", а не строить деревьев, могут сделать программу DT> понятнее. Вот, например, такой класс кольцевого буфера:

DT> class Ring DT> { DT> public: DT> Ring (); DT> bool Empty (void); DT> bool Full (void); DT> bool Put (byte data); DT> byte Get (void); DT> private: DT> void Inc (byte & Idx); DT> byte Next (byte x); DT> byte Head, Tail; DT> qbuf Buf; DT> };

Ээээ.. слюшай, да :) Это не С++, это "С с фичами" :) С++ -это совершенно другой язык, требующий совершенно другого подхода и немного другого видения мира. Вполне жизненный пример из вполне embedded приложения:

//-- abstract base class for memory allocators, //-- provides memory allocation and access API bla-bla-bla class CMemAllocatorBase {...};

//-- Provides memory allocation on a heap class CHeapAllocator: public CMemAllocatorBase {...};

//-- provides memory allocation in a shared memory regions class CSharedMemoryAllocator : public CMemAllocatorBase {...}

/** Ring buffer template class @param TElement type of the buffer element @param TAllocator memory allocator @param nOverflowModel specifies how to handle buffer overflow

*/ template<class TElement, class TAllocator, int nOverflowModel>

class CRingBuffer {...};

//-- let's have queue of TInt16 on a heap, discard head on overflow typedef CRingBuffer<TInt16, CHeapAllocator, DiscardHead> TMyQueue1;

TMyQueue1* pQueue1 = TMyQueue1::Create(125); pQueue1->PutElement(0x23);

//-- let's have queue of TByte in a shared memory, discard tail on overflow typedef CRingBuffer<TByte, CSharedMemoryAllocator, DiscardTail> TMyQueue2;

TMyQueue2* pQueue2 = TMyQueue2::Create(0x40000);

//-- let's have queue of TMyStruct in a shared memory, discard tail on overflow TMyStruct {...}

typedef CRingBuffer<TMyStruct, CSharedMemoryAllocator, DiscardTail> TMyQueue3;

TMyQueue3* pQueue3 = TMyQueue2::Create(0x200);

Что скажут народные академики ? ;)

Dmitry

Reply to
Dmitry Lyokhin

Привет, Dimmy !

30 Sep 05 , 06:48 Dimmy Timchenko писал к Olga Nonova: [skip] DT> class Ring DT> { DT> public: DT> Ring (); DT> bool Empty (void); DT> bool Full (void); DT> bool Put (byte data); DT> byte Get (void); DT> private: DT> void Inc (byte & Idx); DT> byte Next (byte x); DT> byte Head, Tail; DT> qbuf Buf; DT> }; [skip]

(задумчиво) при таком описании Next и Inc на практике инлайнятся?

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... юркие е-стеренки и i-стероиды

Reply to
Nickita A Startcev

Hello Dmitry.

Fri Sep 30 2005 19:37, Dmitry Lyokhin wrote to me:

DL> Ээээ.. слюшай, да :) DL> Это не С++, это "С с фичами" :)

Так я выше об этом и писал. Где-то это даже паскаль. ;) Что делать, Ады нет, приходится варить суп из топора.

DL> С++ -это совершенно другой язык, требующий совершенно другого подхода DL> и немного другого видения мира.

Уж слишком другого видения. Твой пример мне кажется совершенно непрозрачным, хотя, конечно, это уже готовый библиотечный модуль на все случаи жизни. Hо так или иначе тебе надо держать в голове всё это дерево классов и не путаться в их взаимосвязях и "таблицах фич", я же стараюсь делать функции и модули как можно более простыми и атомарными.

Dimmy.

Reply to
Dimmy Timchenko

Hello Nickita.

Sat Oct 01 2005 02:26, Nickita A Startcev wrote to me:

DT>> private: DT>> void Inc (byte & Idx); DT>> byte Next (byte x); DT>> byte Head, Tail; DT>> qbuf Buf; DT>> };

NAS> [skip]

NAS> (задумчиво) при таком описании Next и Inc на практике инлайнятся?

Должны...

Dimmy.

Reply to
Dimmy Timchenko

Hello Dimmy.

01 Oct 05 04:50, you wrote to me:

DT> Так я выше об этом и писал. Где-то это даже паскаль. ;) Что делать, DT> Ады нет, приходится варить суп из топора.

DL>> С++ -это совершенно другой язык, требующий совершенно другого DL>> подхода и немного другого видения мира.

DT> Уж слишком другого видения. Твой пример мне кажется совершенно DT> непрозрачным, хотя, конечно, это уже готовый библиотечный модуль на DT> все случаи жизни. Hо так или иначе тебе надо держать в голове всё это DT> дерево классов и не путаться в их взаимосвязях и "таблицах фич", я же DT> стараюсь делать функции и модули как можно более простыми и DT> атомарными.

.. переписывая их каждый раз при необходимости ввести новый тип данных или еще чего ;)

Dmitry

Reply to
Dmitry Lyokhin

ON> Про Java- это само собой. И все же меня интересует: разве С++ отличается ON> от ON> просто С не возможностью обьектного программирования? Причем достоинства

Кто вам такую чушь сказал? Это разные языки. Как C++ и Java.

ON> такого программирования по-настоящему расскрываются в условиях, когда ON> "нужно ON> постоянно создавать и уничтожать экземпляры классов"?

Только при чём тут ссылки на методы?

Reply to
Kirill Frolov

ON>> Это и есть основной вопрос - а нужен ли нам С++? DT> В C++, кроме классов, есть ещё много полезных усовершенствований. DT> Строчные DT> комментарии, объявления const, inline, передача аргументов по ссылке, DT> объявление параметра цикла в заголовке цикла, более строгая проверка

Многое из этого есть в GCC (частично в C99). Без ++.

Reply to
Kirill Frolov

Hello Dmitry.

Sat Oct 01 2005 11:09, Dmitry Lyokhin wrote to me:

DT>> все случаи жизни. Hо так или иначе тебе надо держать в голове всё DT>> это дерево классов и не путаться в их взаимосвязях и "таблицах фич", DT>> я же стараюсь делать функции и модули как можно более простыми и DT>> атомарными.

DL> .. переписывая их каждый раз при необходимости ввести новый тип данных DL> или еще чего ;)

Делов-то. ;) А иначе приходим к "программированию мышью", примерно как в Дельфи. Hастраивать все эти "properties" гигантских "компонентов" и получать многомегабайтный код - это уже не программирование, а разврат.

Dimmy.

Reply to
Dimmy Timchenko

DL> .. переписывая их каждый раз при необходимости ввести новый тип данных DL> или еще DL> чего

Hадо просто отказаться от типов данных...

Reply to
Kirill Frolov

Hello Kirill.

Sun Oct 02 2005 04:12, Kirill Frolov wrote to Dmitry Lyokhin:

DL>> .. переписывая их каждый раз при необходимости ввести новый тип DL>> данных или еще чего

KF> Hадо просто отказаться от типов данных...

А что в том классе, собственно, от типов данных зависит? Особенно если typedef-ами их описать.

Dimmy.

Reply to
Dimmy Timchenko

Hello Dimmy.

02 Oct 05 07:57, you wrote to Kirill Frolov:

DL>>> .. переписывая их каждый раз при необходимости ввести новый тип DL>>> данных или еще чего

KF>> Hадо просто отказаться от типов данных...

DT> А что в том классе, собственно, от типов данных зависит? Особенно DT> если typedef-ами их описать.

Весь кайф того примера в том и состоит, что от типа данных не зависит ничего, но тем не менее, компилятором осуществляется жесткая проверка используемых типов.

Dmitry

Reply to
Dmitry Lyokhin

DL>>> .. переписывая их каждый раз при необходимости ввести новый тип DL>>> данных или еще чего KF>> Hадо просто отказаться от типов данных... DT> А что в том классе, собственно, от типов данных зависит? Особенно если DT> typedef-ами их описать.

Сам класс -- это тип.

Reply to
Kirill Frolov

Hello Kirill.

Mon Oct 03 2005 00:46, Kirill Frolov wrote to me:

KF>>> Hадо просто отказаться от типов данных... DT>> А что в том классе, собственно, от типов данных зависит? Особенно DT>> если typedef-ами их описать.

KF> Сам класс -- это тип.

Да неужели? :)

Вообще в C++ понятие типа какое-то вяленькое, всё в эти самые классы пошло. typedef - практически определение синонима, не более.

Dimmy.

Reply to
Dimmy Timchenko

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.