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


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


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


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


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

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


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

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


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


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



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

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

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

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


Именно так.


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

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

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


не знаю что вы там сложного нашли.. Классы? так те же структуры. шаблоны? по моему гораздо сложнее их на С реализовывать через убогие макросы. несколько лишних ключевых слов? можно и не запоминать, есть для этоо тетрадка.
Мне после С так вообще такой же, только удобнее. там где были f(&inst) стали inst.f(),
где было куча макросов - стали шаблоны. где были таблицы с функциями - вообще похерились, и генерит их теперь компилятор.
Хотя вру, иногда приходилось писать под Qt, мож по этому мне плюсы не такие уж сложные

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

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

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

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

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

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

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


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

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


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

Вот набрёл на библиотеку С++
http://xpcc.sourceforge.net/api/main.html

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

Лет 20 назад один из заказчиков (пожилой американский менеджер) заранее потребовал писать код безо всяких ++. На вопрос почему, сказал, что за жизнь насмотрелся на море плохого С++ кода.
А теперь я могу вслед за ним повторить эту фразу. Более того, почти в 60% случаев кажется , что C++ используют не язык, а как средство самоутверждения.

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

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

+100

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

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

Господа критикующие, напоминаю, тема звучит Как писать на С++ при создание приложений под ARM, Примеры
Это означает, что автора интересует ответ на вопрос именно как писать на С++, а вовсе не причины почему этого не следует делать.
Я не призываю переносить религиозную полемику в другую тему ибо поезд уже ушёл и огромное количество разработчиков давно и успешно программируют под МК именно на C++.
И пугать нас своей шоблой пожилых американских менеджеров также не нужно.

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


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