Ссылка - https://habrahabr.ru/post/308550/

Наконец-то выразили словами то, что я всегда хотел сказать.

Т.е. для малых встраиваемых систем на Cortex-M3..M7, или для 8-и битников подавно преимущества C++ сводятся к нулю.
Поскольку в проектах для них задействовано слишком мало программистов. Нужно не меньше сотни.

А большее влияние на скорость разработки оказывают параметры IDE.
В частности скорость компиляции.
Поскольку это определяют культуру проектов.

Не согласен, что именно IDE определяет скорость компиляции и тем более культуру программирования. Использование редактора, компилятора, СУВ и make без лишних сущностей в виде IDE зачастую требует большей культуры, строгости и т.д. и т.п. Но это слишком субъективно и не совсем по теме, не мог пройти мимо

вот уж скорость компиляции для "малых встраиваемых систем" вообще не заметна должна быть.
а цифры в статье высосаны непонятно из чего.
и для малых встраиваемых систем какой-нибудь простенький ГУЙ, например, с плюсами, даже одним человеком, пожалуй будет веселее и писАться, и затем читаться, чем на просто С, ну пусть и на 10-20%.
а писать обёртки на С++ для какого-нибудь GPIO и таймеров пожалуй действительно баловство.
ну и даже если плюсы не ускоряют разработку на небольших проектах, их надо теперь отовсюду выпилить что ли и запретить, мешают они кому-то?

Это больше всего удивило в статье. Так можно было бы не 7% написать, а любое другое...

Да, наверно понятие "культура" здесь сильно многозначное, сложно вокруг него дискутировать.

Но я здесь имел в виду то, как делится проект на файлы и библиотеки, какие средства отладки интегрируются в исходники и как используются.
Сколько версий создается и существует одновременно, как планируется время для отладки и какие средства на неё выделяются и т.д.
Строгость или дисциплина тут не при чём.

Очень понравился комментарий:
Полностью согласен. Статья - ерунда.

Ну это уже не малые будут, а примитивные.

Проект с микролинуксом компилироваться может десятки минут, .NET micro framework тоже не меньше 15 мин компилируется.
Те же RTOS со всем middleware компилируются по 5 мин и дольше.

Чтобы накомпилить 1 мег бинарника не меньше 10 мин надо. А в GCC и все полчаса.

Не согласен с топикстартером. А статья написана в стиле сумасшедшего бреда, обсуждают среднюю температуру по больнице.

Код на С++ лучше структурирован - а значит легче для понимания. Если ваша программа занимает 1-2 экрана - не важно, на каком языке пишете, берите любой из популярных который лучше знаете. Но если это программа для прибора с датчиками, протоколами, алгоритмами и конечными автоматами - С++ будет намного эффективнее. Полиморфизм, инкапсуляция и шаблоны дадут более компактный, простой и человекочитаемый код. В простом коде сложнее допустить ошибки, его легче поддерживать.

Я писал на Ассемблере и Си для PIC и Avr, а год назад свой проект под M3 переписывал на Си++. Код стал красивее

Так не о красоте же речь.
Вот гарантию даю, я скобочками, отступами, раскраской и подбором имён сделаю код на С-и красивее вашего.

Кажется вы пропустили абзац в моем посте. Я не только о красоте говорил.
Чем больше программа, тем эффективнее в ней будет применение высокоуровнего языка. Это - факт.

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


Это скользкая оценка. Как, например, измерить эффективность языка программирования? И насколько это "намного" эффективнее?


У меня возникают похожие мысли.


А если на заключительном этапе разработки в базовом классе обнаружен баг и его исправление затронет все производные от него структуры с последующим затратным тестированием?
Будет ли это эффективно?
По поводу объемов кода...
Читал я об использовании несколько лукавого критерия "количество строк кода" при оценке целесообразности применения C или C++ для конкретного проекта:
- до 10 000 применять C;
- от 10 000 до 100 000 возможны варианты C/C++;
- от 100 000 применять C++.
Мои личные ощущения в целом согласуются с таким подходом.
Для написания математического ядра или эмбеддерства мои проекты не вылазили за 20 000 строк, поэтому стойкой потребности в языке с развитыми средствами ООП не возникало.
Периодически заглядываю в исходники модулей ядра и дровишек для Linux и тоже в основном все понятно в чужом коде на чистом C.
Явное и естественное желание использовать ООП возникло при обдумывании GUI оберток, где все может меняться налету, наследоваться, бегать, прыгать, скакать и масштабироваться.
В более низкоуровневой области использование ООП напрашивается при описании хитровывернутых протоколов с кучей настроек, режимов и свистелок.

То что код будет компактный - это вовсе не значит что он будет более читабельный и его удобней поддерживать.

Когда у тебя (а хуже когда в чужом коде, который ты поддерживаешь) куча многоэтажных (причем ПЕРЕКРЕСТНЫХ) иерархий классов, шаблонов, перегрузок и виртуальных функций, то чтобы понять какой же код на самом деле у тебя здесь работает нужно перелопатить всю иерархию и просмотреть все варианты перегрузки и проанализировать шаблоны.
Отладка и поиск бага в такой программе то ещё "удовольствие".

И получается, что когда нужно ДЕТАЛЬНО понять что конкретно и где у тебя вызывается (а не просто получить общее "абстрактное" представление о коде) как же работает данный код, то в страничке кода на С++ можно разбираться НЕДЕЛЮ.

Т.е. ООП направлен на скрытие "несущественных деталей".
А как быть если копаться в этих "деталях" и искать в них баги как раз и есть твоя работа?
А их от тебя "скрыли". Чем усложнили твою работу

В современной парадигме ООП для того чтобы всё корректно наследовалось, перегружалось и пр - принято плодить много однострочных методов.
метод длиннее 20 строк? надо рефакторить!

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

Вообще, у меня сложилось впечатление, что приличное количество программистов переняли себе определенный стиль поведения, сходный с дорожными рабочими. В духе - зачем сразу делать качественные дороги, когда можно делать некачественные и потом бесконечно их ремонтировать?
Зачем сразу писать код, который будет гарантированно работать, и лишать тем самым себя стабильного заработка на среднесрочную перспективу?
Ведь переключение на написание другой программы потребуется опять РАЗБИРАТЬСЯ с тем что должно быть реализовано, знакомиться с новой предметной областью. А это надо мозгами опять шевелить, а не куски методов туда-сюда копипастить. Лень.

вот писали бы все сишники и плюшники на объект-паскале и не парили людям моск

На эту тему есть фейковое интервью Страуструпа, но как раз про это.
Если кто не видел оригинал прикола http://www.erenkrantz.com/Humor/FakeIEEESt...Interview.shtml
Перевод http://archive.is/tC8ZR

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


Похоже, что интервьювер попадает под статью о защите диких животных - аналогичный уровень интеллекта.


правильно ответил. наверно тут и надо было закончить интервью.


закрыл вкладку и дальше не читал. это как гладить холодильником - ну, сзади же тёплое.

PS. отдаю должное тов. AlexandrY. В течение последних нескольких дней он заметно встрепенул "отпускной" форум холиварами. Маладэсь.

Отдаю должное посту свыше от smalcom- встретились бы мы в реальной жизни, пожал бы Вам руку и проставился пивом Одним словом- поддерживаю на все 100. Что касается:



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

а-а-а, вот оно что.

Тема сия - мегахоливарная. Уже несколько таких было. Тысячу раз перемололи и С, и С++, и ООП. Граждане, окститесь, ну зачем вам это снова?
На Хабре недавно наткнулся на переводную статью (ссылку приводить не буду) о том что ООП бесполезно и вообще умерло И это уже не первый случай публикования ереси для Хабра. Так что рассматривать этот ресурс серьезно не стоит (пмсм).
Меня лично мало беспокоит, кто на чем программирует для эмбеда, если это не касается моих коллег
Недавно у нас был индус-практикант из TUDelft. Чтоб экстренно прервать измерительную процедуру, написанную на Питоне, он выключал электрометр Keithley, с которым программа общалась по GPIB. А вы тут про С++ в МК...

Так потому и холиварная, что реально разницы в производительности программирования что на C, что на C++ нет.
Тем более статья так совпала с моим личным опытом.
А у меня знаете ли под сотню проектов. И с ООП и без ООП. Прямо сейчас поддерживаю 50 программных проектов.

Да и область обсуждения я сузил только определенным сценарием разработки и только для определенного класса систем.
Тут все гораздо однозначней.

А если граждане холиварят значит их это волнует. Почему мы не должны говорить о том что нас волнует?
Или в мире ничего не меняется, и мы будем смотреть в рот Страуструпу который и Cortex-M4 в руках то не держал?

Другое дело когда в дискуссию лезут просто посторонние, обычно тролящие в теме про PCB. Это уже местного модератора проблема должна быть.

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

Не знаю, как у Вас, а у меня поддержка проектов в основном - это изменение функционала по пожеланиям клиентов.
Т.е. девайсы продаются своим чередом, но у клиентов (как старых так и новых) изредка возникает желание что-то изменить в функционале.
Прибыль мы получаем от продажи устройств. А поддержка ПО позволяет расширять продажи.
По запросам клиентов формируется новая версия ПО, которую они могу взять с сайта и самостоятельно обновить программу в устройстве.

А теперь давайте представим, у "AlexandrY" около 50 проектов на контроле. Если по каждому из них возникает потребность что-то изменить хотя бы раз в год, каждую неделю перед службой поддержки ставится новая задача.
У меня тоже около 10 проектов в поддержке, поэтому представляю, что это такое.

Я как бы однажды писал, что успешные проекты у меня делаются строго без ТЗ.
Поэтому такого понятия как "хорошая" программа быть не может просто из-за отсутствия каких либо требований к программе.

Есть только представление об удобстве использования, надежности, безопасности для людей и допустимом объеме тех. обслуживания.

Самореклама - отличная вещь!
Смысла топика не понял - бросать C/C++? А что вместо него ставить? С++ и сейчас один из самых сложных языков, сползти на другие - не думаю, что шибко сложно.

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

Но знать куда двигаться не стоит тоже полезно.

C сделали, когда надоело каждый раз под новую железку писать с нуля новую ОС.

C++ же- это дальнейшее развитие базового языка C, позволяющее более удобно и понятно "транслировать" некоторую бизнес/деловую часть реального мира(с объектами и их связями) в программный код. Причём C полностью входит в C++.

Оба инструмента прекрасно выполняют возложенные на них задачи. Как пример: Linux(Cи) и Unreal Engine(C++).

Тут уже писали, что для каждого инструемнта есть свой класс задач. И в своём классе задач определённый инструмент действительно повышает эффектиность разработки(объём строк и символов в отношении к реализованному решению задачи + скорости исполнения и объёму исполняемого файла), т.к. не просто заточен под это, а создан для этого.

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

что таких как вы я не рекомендую к найму.


не надо юлить. Уже в собственном троллинге запутались. А, вы так думаете? Искренне сочувствую, всегда сочувствую блаженным.

А можете это логически доказать, или с помощью аналогий?

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

Статья как раз говорит, что нет никаких таких классов задач особенных для C или C++.
Просто чтобы C++ показал эффективность он должен использоваться в проекте с толпой народу.

Ох, зря Вы так...

Есть несколько типовых примеров. Один озвучу.

Числа бывают разные: действительные, натуральные, целые, рациональные, иррациональные, комплексные.

Попробуйте реализовать работу с комплексными числами на Си и С++.
Если интересно, можете глянуть вариант на С++ в книге Дж. Коплиена.

А потом скажите, где более эффективная и понятная реализация(легче поддерживаемая и развиваемая, к примеру).

не тратьте ваши нервы. посмотрите последние созданные им темы и сообщения. человик или тролль или потерян для общества навсегда.

Известный аргумент.
Но! Комплексные числа это такая мелочь приближающаяся по своему значению к нулю во встраиваемых системах.
Спросите здесь программистов, кто на Cortex-M4 использовал комплексные числа хоть раз в жизни.
Я ни разу!
Хотя нет, наверно использовал, но это всегда скрыто было в готовых библиотеках.

Но ладно, по существу метод предложенный Коплиен Дж. Программирование на C++ (2005) на странице 99 весьма специфичен и требует перестройки мышления.
Т.е. переходя к комплексным числам нужно вспомнить что там некоторые операторы перегружены, причем не все. Чтобы узнать какие вам надо влезть в этот класс и подробно его рассмотреть
Это у вас будет убивать хороший кусок времени каждый раз при возвращении к работе с этими числами.
Потом как интересно вы будете смотреть на эти числа в отладчике.
IAR навороченная среда, но даже он в таком виде комплексные числа не показывает. Вам придется лезть каждый раз в недра объекта.

По сути класс Коплиен-а экономит пару скобочек и запятых, считай считанные секунды или минуты на протяжении года работы программиста. Но усложнит отладку и поддержку, а это уже гораздо серьезней, тут речь о часах.

человек, неразбирающийся в С++, не авторитетен в вопросе выбора языка из списка, где С++ присутствует.

ps. всё-таки не тролль. жаль, очень жаль.

Admin: устное предупреждение - переход на личности нарушает правила форума. Продолжение в том же духе приведёт к повышению уровня предупреждений отдельных участников и закрытию этой темы.

Из инета: "...С++ вреден для мозга... Погружение программиста в С++ неизбежно приводит к тому, что он наполняет проект ненужными сложностями, которые кажутся ему «замечательными» и «способствующими разработке», но в действительности ухудшают модифицируемость до такой степени, что отдельно взятый компонент невозможно доработать без переписывания всего приложения с нуля..."
Как раз примеры, подобные комплексным числам в С++, и оттолкнули меня от "погружения" в С++. В той-же книге Дж. Коплиена как раз на примере комплексных чисел и разбираются некоторые из множества граблей.

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

Отладку- нет, поддержку- нет; т.к. время для вникания составляет 20 минут от силы, потому как там всё просто и понятно реализовано(у Коплиена).

На "синтетических" (специально придуманных, чтобы показать преимущества того или иного языка, задачах) примерах все хорошо и блестяще выглядит. Взять хотя бы классический пример "точка, круг, круг в квадрате", который почти во всех книгах по ООП приводится.

Но только когда дело касается РЕАЛЬНЫХ, а не надуманных задач, то тут то и начинается целый геморрой.

Не случайно же на "чистом" С++ практически никто из программистов не пишет.
Все используют разного рода фреймворки, надстройки, проблемно-ориентированные библиотеки и прочие DSL-и


Именно так.
В С++ программе можно только "наследоваться" и перегружать.
Но не дай Бог лезть в базовые классы.
Рискуешь обрушить всю иерархию и гигабайты уже написанного кода

это надо расценивать так, что вы smalcom каждый ваш проект лезете перегружать, например, в iostream?

Тема закрыта.