[andrewlekar 0]

О как! Сильно сказано. Только вот как раз ООП и придумано для того, чтобы можно было не сократить, а полностью ликвидировать утечки памяти - просто нужно тщательно продумать структуру программы и распределение объектов. И выделять память в конструкторе объекта, а удалять в деструкторе. Тогда их не будте никогда. Разве что у тех программистов, которые так и не поняли смысл объектно-ориентированного программирования.

Ах, оставьте свой религиозный пыл для неофитов. :)

 

То есть если в некоем языке есть фича которую вы не понимаете или с которой у вас когда-то были проблемы - то это плохой язык. Вот тот у которого нет такой фичи - хороший.

А теперь прокомментируйте, почему в более современных Java и C# множественное наследование вырезано.

 

Зачем? Вот убей не пойму, почему когда пишут прикладную программу для обычного компьютера, она не требуется, а в микроконтроллерах непременно нужна?

Потому что специфика применения микроконтроллеров, ограниченность ресурсов, как правило отсутствие виртуальной памяти, нехватка времени и людей. Если у вас со всем этим проблем не наблюдается, так можете без адресной арифметики писать код.

 

Динамическое размещение объектов встречается везде, но в C нет средств для аккуратной работы с ними, а в C++ есть.

Нет не везде. У меня в коде не было динамического размещения объектов, пока не пришлось туда запихать lwIP.

 

Да, это серьезный недостаток! На С можно писать и без головы, только... не хотелось бы мне пользоваться таким устройством.

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

[dxp 65]

Что значит "не нужны"? Что значит "сами по себе"? (почти) всё перечисленное - свойства ООП. Поскольку все это есть в С++, то он является объектно-ориентированным языком.

Как и предполагалось, вы неверно понимаете термин "объектно-ориентированный". Для вас класс С++ - уже ОО, а это не так. ООП - это когда программа построена на основе полиморфного поведения объектов, т.е. когда явно присутствует иерархия классов с виртуальными функциями - методами. Именно это и только это в С++ является объектно-ориентированным подходом. Просто классы даже с наследованием, но без виртуальных функций, не несут ООП, это обычный объектный подход.

 

Я понимаю, фаллометрия очень важна для посетителей этого форума.

С этим вы к себе обратитесь.

[777777 0]

Ах, оставьте свой религиозный пыл для неофитов. :)

Что значит "религиозный"? Предложение использовать интсрумент только по назначению вы считаете религиозным пылом? Ну да, настоящие пцаны могут и микроскопом гвозди забивать, даже не той стороной.

 

Потому что специфика применения микроконтроллеров, ограниченность ресурсов, как правило отсутствие виртуальной памяти, нехватка времени и людей. Если у вас со всем этим проблем не наблюдается, так можете без адресной арифметики писать код.

Я надеялся увидеть конкретный пример.

 

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

Да, здесь вы конечно правы. Но самолетом управлять тоже сложно, но несмотря на это никто их за это не критикует и не требуют запретить.

 

 

Как и предполагалось, вы неверно понимаете термин "объектно-ориентированный". Для вас класс С++ - уже ОО, а это не так. ООП - это когда программа построена на основе полиморфного поведения объектов, т.е. когда явно присутствует иерархия классов с виртуальными функциями - методами. Именно это и только это в С++ является объектно-ориентированным подходом. Просто классы даже с наследованием, но без виртуальных функций, не несут ООП, это обычный объектный подход.

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

 

Во-вторых, я даже не представляю где вы выкопали такое определение. Обязательными составными частями ОО всегда считались инкапсуляция, наследование, полиморфизм. Все они есть в С++, о чем еще может быть спор? Или если некая конкретная программа не использует полиморфизм, то она уже не объектно-ориентированная? Но речь вроде бы о языке, а не о программах.

 

Наконец, последние слова меня привели в полное замешательство: "...без виртуальных функций, не несут ООП, это обычный объектный подход". Это не опечатка? ООП и "объектный подход" чем-то отличаются?

 

[dxp 65]

Во-вторых, я даже не представляю где вы выкопали такое определение. Обязательными составными частями ОО всегда считались инкапсуляция, наследование, полиморфизм.

Только полиморфизм. Динамический. Икапсуляция и абстракция - это объектный подход.

 

Или если некая конкретная программа не использует полиморфизм, то она уже не объектно-ориентированная?

Именно так.

 

ООП и "объектный подход" чем-то отличаются?

Я уже неоднократно и подробно излагал на этом форуме по поводу парадигм программирования, в последний раз не более полугода назад. Повторять лень. Если интересуетесь, поищите по форуму.

 

Насчёт того, что классы С++ - это уже ООП, это распространённая ошибка. Сравните С++ с true ОО языком - например, со SmallTalk.

[brag 0]

очитайте про "Placement new". Это прояснит многие вопросы, в том числе и про выделение в разных секциях

Я их смотрел, когда под плюсы код переводил. Особо от них легче не становится - надо выделять буфферы в статике, не забыть вызвать тот самый new, да и еще с thread safety, скорее всего, возится прийдется. в итоге аналог init(...) получается, только кроме того, надо держать еще указатель на обьект, а это аж 4 байта памяти :)

 

У C++ сложность, на мой взгляд, самая высокая из современных языков. Даже хаскелл уступает в этом плане.

не знаю что вы там сложного нашли.. Классы? так те же структуры. шаблоны? по моему гораздо сложнее их на С реализовывать через убогие макросы. несколько лишних ключевых слов? можно и не запоминать, есть для этоо тетрадка.

Мне после С так вообще такой же, только удобнее. там где были f(&inst) стали inst.f(),

где было куча макросов - стали шаблоны. где были таблицы с функциями - вообще похерились, и генерит их теперь компилятор.

Хотя вру, иногда приходилось писать под Qt, мож по этому мне плюсы не такие уж сложные :)

[Гость MALLOY2]

Ссылка в тему С++ & Cortex

[brag 0]

Хe, и множественному наследованию (по крайней мере двойному) нашлось применение.

 

Есть некий класс A. он должен принимать сообщения заданного формата и отправлять ответы тоже заданного формата, но через независящий от класса А и неизвестный ему интерфейс(это может быть sms,sockets,keyboard/display,...)

class A{
private:
     CommIf *commif;
}

Класс CommIf тот самый интерфейс

class CommIf{
public:
    virtual int cmdCbkSend(const void*,U32)=0;
};

Класс а читает с какого-нибудь thread-safe fifo данные, первое слово в этом fifo - у казатель на что-то производное от CommIf.

Fifo.read(&commif,sizeof(commif));

Далее в fifo могут лежать произовльные данные, их можно от туда дочитывать итд. далее,если ему надо отправить ответ - он просто вызывает commif->cmdCbkSend() и кормит ему буффер с данными

 

Теперь реализация самого интерфейса(будь то смс или соктеы,..)

class Smsiface : public Sms,public CommIf{
public:
   // reimplemented virtuals for CommIf
    int cmdCbkSend(const void *d,U32 n){return sendSms(0,d,n);}
protected: // reimplemented virtuals for Sms
    void smsReceived(int ep,const void *data,U32 len);
};

void Smsiface::smsReceived(int ep,const void *data,U32 len){
    CommIf *commif=static_cast<CommIf*>(this);
    Fifo.write(&commif,sizeof(commif));
}

 

Все. Смсы,сокеты,итд живут в отдельных тредах независимо друг от друга и от класса A(который тоже живет в отдельном треде).

Подобную хрень я делал и на С, но там запарится можно, пока все отладишь, все хождения по указателям, а на плюсах написал и работает ;)

[andrewlekar 0]

Множественное наследование от интерфейсов разумеется разрешено. А вот множественное наследование реализации запрещено в современных ОО языках. Так что тут вы велосипед изобрели. :)

 

где было куча макросов - стали шаблоны. где были таблицы с функциями - вообще похерились, и генерит их теперь компилятор.

Ну а у меня наоборот: где была невнятная иерархия классов, требующая в дополнение к собственно программе диаграмму зависимостей, появился чистый и понятный код на сях. Где были утечки памяти, вопросы, где вызывать delete, а где delete[], нарушение инкапсуляции (да, в с++ трудно добиться честной инкапсуляции) - всё стало статично и разбито на независимые модули.

[Faris 1]

Вот набрёл на библиотеку С++

http://xpcc.sourceforge.net/api/main.html

 

Есть кое-что и для ARMов

[kikos 0]

Лет 20 назад один из заказчиков (пожилой американский менеджер) заранее потребовал писать код безо всяких ++. На вопрос почему, сказал, что за жизнь насмотрелся на море плохого С++ кода.

А теперь я могу вслед за ним повторить эту фразу. Более того, почти в 60% случаев кажется , что C++ используют не язык, а как средство самоутверждения.

 

так что лучше не писать на С++ при создание приложений под ARM...

 

 

[Сергей Борщ 140]

На вопрос почему, сказал, что за жизнь насмотрелся на море плохого С++ кода.

За жизнь много раз приходилось пробовать невкусный чай (кофе). Так что ж теперь, не пить чай(кофе) совсем?

 

[Forger 26]

За жизнь много раз приходилось пробовать невкусный чай (кофе). Так что ж теперь, не пить чай(кофе) совсем?

+100

[ReAl 0]

Более того, почти в 60% случаев кажется , что C++ используют не язык, а как средство самоутверждения.

«лет 20 назад» в около микроконтроллерном мире многие похожее и про С говорили.

 

А сколько тот менеджер в жизни видел некрасивых женщин, у него не интересовались?

 

[IgorKossak 0]

Господа критикующие, напоминаю, тема звучит Как писать на С++ при создание приложений под ARM, Примеры

Это означает, что автора интересует ответ на вопрос именно как писать на С++, а вовсе не причины почему этого не следует делать.

Я не призываю переносить религиозную полемику в другую тему ибо поезд уже ушёл и огромное количество разработчиков давно и успешно программируют под МК именно на C++.

И пугать нас своей шоблой пожилых американских менеджеров также не нужно.

[brag 0]

Как можно реализовать такую вещ без кривоты, rtti, библиотек:

class Base{
public:
    Base(Base *array){ _a=array;}
    Base *getItem(int n){ return &_a[n]; }
private:
    Base *_a;
};

class Derived: public Base{
public:
    Derived(Derived *array) : Base(array){}
private:
    int other;
};

Derived aaa[]={Derived(0),Derived(0),Derived(0)};
Derived d(aaa);

 

Ессно, при вызове d.getItem(1) мы получим мусор, вместо &aaa[1]. Сейчас сделал через массив указателей - вместо Base *array передается и хранится Base * const *array, но задолбало лепить эти массивы вручную, а на такое компиллер матерится, типа юзание временного обьекта:

Derived *aaa[]={&Derived(0),&Derived(0),&Derived(0)};