Ссылка - 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 оберток, где все может меняться налету, наследоваться, бегать, прыгать, скакать и масштабироваться.
В более низкоуровневой области использование ООП напрашивается при описании хитровывернутых протоколов с кучей настроек, режимов и свистелок.

Сообщение отредактировал BackEnd - Aug 27 2016, 03:57

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

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

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

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

Сообщение отредактировал Укушенный воблой - Aug 27 2016, 07:41

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

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

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

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

Сообщение отредактировал Огурцов - Aug 27 2016, 08:30

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