andrewlekar 0 23 сентября, 2011 Опубликовано 23 сентября, 2011 · Жалоба О как! Сильно сказано. Только вот как раз ООП и придумано для того, чтобы можно было не сократить, а полностью ликвидировать утечки памяти - просто нужно тщательно продумать структуру программы и распределение объектов. И выделять память в конструкторе объекта, а удалять в деструкторе. Тогда их не будте никогда. Разве что у тех программистов, которые так и не поняли смысл объектно-ориентированного программирования. Ах, оставьте свой религиозный пыл для неофитов. :) То есть если в некоем языке есть фича которую вы не понимаете или с которой у вас когда-то были проблемы - то это плохой язык. Вот тот у которого нет такой фичи - хороший. А теперь прокомментируйте, почему в более современных Java и C# множественное наследование вырезано. Зачем? Вот убей не пойму, почему когда пишут прикладную программу для обычного компьютера, она не требуется, а в микроконтроллерах непременно нужна? Потому что специфика применения микроконтроллеров, ограниченность ресурсов, как правило отсутствие виртуальной памяти, нехватка времени и людей. Если у вас со всем этим проблем не наблюдается, так можете без адресной арифметики писать код. Динамическое размещение объектов встречается везде, но в C нет средств для аккуратной работы с ними, а в C++ есть. Нет не везде. У меня в коде не было динамического размещения объектов, пока не пришлось туда запихать lwIP. Да, это серьезный недостаток! На С можно писать и без головы, только... не хотелось бы мне пользоваться таким устройством. Передергиваете, батенька. Есть такое понятие, как сложность языка. Проще говоря, сколько дров вы наломаете, прежде чем на нем что-то напишете и сколько денег потеряете, разбираясь с багами во время работы готового кода. У C++ сложность, на мой взгляд, самая высокая из современных языков. Даже хаскелл уступает в этом плане. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 23 сентября, 2011 Опубликовано 23 сентября, 2011 · Жалоба Что значит "не нужны"? Что значит "сами по себе"? (почти) всё перечисленное - свойства ООП. Поскольку все это есть в С++, то он является объектно-ориентированным языком. Как и предполагалось, вы неверно понимаете термин "объектно-ориентированный". Для вас класс С++ - уже ОО, а это не так. ООП - это когда программа построена на основе полиморфного поведения объектов, т.е. когда явно присутствует иерархия классов с виртуальными функциями - методами. Именно это и только это в С++ является объектно-ориентированным подходом. Просто классы даже с наследованием, но без виртуальных функций, не несут ООП, это обычный объектный подход. Я понимаю, фаллометрия очень важна для посетителей этого форума. С этим вы к себе обратитесь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
777777 0 23 сентября, 2011 Опубликовано 23 сентября, 2011 · Жалоба Ах, оставьте свой религиозный пыл для неофитов. :) Что значит "религиозный"? Предложение использовать интсрумент только по назначению вы считаете религиозным пылом? Ну да, настоящие пцаны могут и микроскопом гвозди забивать, даже не той стороной. Потому что специфика применения микроконтроллеров, ограниченность ресурсов, как правило отсутствие виртуальной памяти, нехватка времени и людей. Если у вас со всем этим проблем не наблюдается, так можете без адресной арифметики писать код. Я надеялся увидеть конкретный пример. Передергиваете, батенька. Есть такое понятие, как сложность языка. Проще говоря, сколько дров вы наломаете, прежде чем на нем что-то напишете и сколько денег потеряете, разбираясь с багами во время работы готового кода. У C++ сложность, на мой взгляд, самая высокая из современных языков. Даже хаскелл уступает в этом плане. Да, здесь вы конечно правы. Но самолетом управлять тоже сложно, но несмотря на это никто их за это не критикует и не требуют запретить. Как и предполагалось, вы неверно понимаете термин "объектно-ориентированный". Для вас класс С++ - уже ОО, а это не так. ООП - это когда программа построена на основе полиморфного поведения объектов, т.е. когда явно присутствует иерархия классов с виртуальными функциями - методами. Именно это и только это в С++ является объектно-ориентированным подходом. Просто классы даже с наследованием, но без виртуальных функций, не несут ООП, это обычный объектный подход. Во-первых, я нигде не писал, что язык с классами - уже ОО. Во-вторых, я даже не представляю где вы выкопали такое определение. Обязательными составными частями ОО всегда считались инкапсуляция, наследование, полиморфизм. Все они есть в С++, о чем еще может быть спор? Или если некая конкретная программа не использует полиморфизм, то она уже не объектно-ориентированная? Но речь вроде бы о языке, а не о программах. Наконец, последние слова меня привели в полное замешательство: "...без виртуальных функций, не несут ООП, это обычный объектный подход". Это не опечатка? ООП и "объектный подход" чем-то отличаются? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 23 сентября, 2011 Опубликовано 23 сентября, 2011 · Жалоба Во-вторых, я даже не представляю где вы выкопали такое определение. Обязательными составными частями ОО всегда считались инкапсуляция, наследование, полиморфизм. Только полиморфизм. Динамический. Икапсуляция и абстракция - это объектный подход. Или если некая конкретная программа не использует полиморфизм, то она уже не объектно-ориентированная? Именно так. ООП и "объектный подход" чем-то отличаются? Я уже неоднократно и подробно излагал на этом форуме по поводу парадигм программирования, в последний раз не более полугода назад. Повторять лень. Если интересуетесь, поищите по форуму. Насчёт того, что классы С++ - это уже ООП, это распространённая ошибка. Сравните С++ с true ОО языком - например, со SmallTalk. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
brag 0 23 сентября, 2011 Опубликовано 23 сентября, 2011 · Жалоба очитайте про "Placement new". Это прояснит многие вопросы, в том числе и про выделение в разных секциях Я их смотрел, когда под плюсы код переводил. Особо от них легче не становится - надо выделять буфферы в статике, не забыть вызвать тот самый new, да и еще с thread safety, скорее всего, возится прийдется. в итоге аналог init(...) получается, только кроме того, надо держать еще указатель на обьект, а это аж 4 байта памяти :) У C++ сложность, на мой взгляд, самая высокая из современных языков. Даже хаскелл уступает в этом плане. не знаю что вы там сложного нашли.. Классы? так те же структуры. шаблоны? по моему гораздо сложнее их на С реализовывать через убогие макросы. несколько лишних ключевых слов? можно и не запоминать, есть для этоо тетрадка. Мне после С так вообще такой же, только удобнее. там где были f(&inst) стали inst.f(), где было куча макросов - стали шаблоны. где были таблицы с функциями - вообще похерились, и генерит их теперь компилятор. Хотя вру, иногда приходилось писать под Qt, мож по этому мне плюсы не такие уж сложные :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость MALLOY2 23 сентября, 2011 Опубликовано 23 сентября, 2011 · Жалоба Ссылка в тему С++ & Cortex Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
brag 0 23 сентября, 2011 Опубликовано 23 сентября, 2011 · Жалоба Х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 23 сентября, 2011 Опубликовано 23 сентября, 2011 · Жалоба Множественное наследование от интерфейсов разумеется разрешено. А вот множественное наследование реализации запрещено в современных ОО языках. Так что тут вы велосипед изобрели. :) где было куча макросов - стали шаблоны. где были таблицы с функциями - вообще похерились, и генерит их теперь компилятор. Ну а у меня наоборот: где была невнятная иерархия классов, требующая в дополнение к собственно программе диаграмму зависимостей, появился чистый и понятный код на сях. Где были утечки памяти, вопросы, где вызывать delete, а где delete[], нарушение инкапсуляции (да, в с++ трудно добиться честной инкапсуляции) - всё стало статично и разбито на независимые модули. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Faris 1 5 октября, 2011 Опубликовано 5 октября, 2011 · Жалоба Вот набрёл на библиотеку С++ http://xpcc.sourceforge.net/api/main.html Есть кое-что и для ARMов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kikos 0 31 октября, 2011 Опубликовано 31 октября, 2011 · Жалоба Лет 20 назад один из заказчиков (пожилой американский менеджер) заранее потребовал писать код безо всяких ++. На вопрос почему, сказал, что за жизнь насмотрелся на море плохого С++ кода. А теперь я могу вслед за ним повторить эту фразу. Более того, почти в 60% случаев кажется , что C++ используют не язык, а как средство самоутверждения. так что лучше не писать на С++ при создание приложений под ARM... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 140 31 октября, 2011 Опубликовано 31 октября, 2011 · Жалоба На вопрос почему, сказал, что за жизнь насмотрелся на море плохого С++ кода.За жизнь много раз приходилось пробовать невкусный чай (кофе). Так что ж теперь, не пить чай(кофе) совсем? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Forger 26 31 октября, 2011 Опубликовано 31 октября, 2011 · Жалоба За жизнь много раз приходилось пробовать невкусный чай (кофе). Так что ж теперь, не пить чай(кофе) совсем? +100 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 1 ноября, 2011 Опубликовано 1 ноября, 2011 · Жалоба Более того, почти в 60% случаев кажется , что C++ используют не язык, а как средство самоутверждения.«лет 20 назад» в около микроконтроллерном мире многие похожее и про С говорили. А сколько тот менеджер в жизни видел некрасивых женщин, у него не интересовались? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 1 ноября, 2011 Опубликовано 1 ноября, 2011 · Жалоба Господа критикующие, напоминаю, тема звучит Как писать на С++ при создание приложений под ARM, Примеры Это означает, что автора интересует ответ на вопрос именно как писать на С++, а вовсе не причины почему этого не следует делать. Я не призываю переносить религиозную полемику в другую тему ибо поезд уже ушёл и огромное количество разработчиков давно и успешно программируют под МК именно на C++. И пугать нас своей шоблой пожилых американских менеджеров также не нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
brag 0 10 декабря, 2011 Опубликовано 10 декабря, 2011 · Жалоба Как можно реализовать такую вещ без кривоты, 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)}; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться