Jump to content

    
Sign in to follow this  
AlexandrY

Отличная статья про соотношение C и C++

Recommended Posts

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

 

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

 

Т.е. для малых встраиваемых систем на Cortex-M3..M7, или для 8-и битников подавно преимущества C++ сводятся к нулю.

Поскольку в проектах для них задействовано слишком мало программистов. Нужно не меньше сотни.

 

А большее влияние на скорость разработки оказывают параметры IDE.

В частности скорость компиляции.

Поскольку это определяют культуру проектов.

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

вот уж скорость компиляции для "малых встраиваемых систем" вообще не заметна должна быть.

а цифры в статье высосаны непонятно из чего.

и для малых встраиваемых систем какой-нибудь простенький ГУЙ, например, с плюсами, даже одним человеком, пожалуй будет веселее и писАться, и затем читаться, чем на просто С, ну пусть и на 10-20%.

а писать обёртки на С++ для какого-нибудь GPIO и таймеров пожалуй действительно баловство.

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

 

Share this post


Link to post
Share on other sites
а цифры в статье высосаны непонятно из чего.

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

Share this post


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

 

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

 

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

Сколько версий создается и существует одновременно, как планируется время для отладки и какие средства на неё выделяются и т.д.

Строгость или дисциплина тут не при чём.

 

Share this post


Link to post
Share on other sites

Очень понравился комментарий:

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

Share this post


Link to post
Share on other sites
вот уж скорость компиляции для "малых встраиваемых систем" вообще не заметна должна быть.

 

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

 

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

Те же RTOS со всем middleware компилируются по 5 мин и дольше.

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites
Я писал на Ассемблере и Си для PIC и Avr, а год назад свой проект под M3 переписывал на Си++. Код стал красивее :)

 

Так не о красоте же речь.

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

Share this post


Link to post
Share on other sites
Так не о красоте же речь.

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

 

Кажется вы пропустили абзац в моем посте. Я не только о красоте говорил.

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

Share this post


Link to post
Share on other sites
Код на С++ лучше структурирован - а значит легче для понимания.

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

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

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

Однако предположение за 15 лет так и не оправдалось, устройство просуществовало в одном варианте со всеми избыточными наворотами кода.

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

 

Но если это программа для прибора с датчиками, протоколами, алгоритмами и конечными автоматами - С++ будет намного эффективнее.

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

 

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

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

 

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

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

Будет ли это эффективно?

По поводу объемов кода...

Читал я об использовании несколько лукавого критерия "количество строк кода" при оценке целесообразности применения C или C++ для конкретного проекта:

- до 10 000 применять C;

- от 10 000 до 100 000 возможны варианты C/C++;

- от 100 000 применять C++.

Мои личные ощущения в целом согласуются с таким подходом.

Для написания математического ядра или эмбеддерства мои проекты не вылазили за 20 000 строк, поэтому стойкой потребности в языке с развитыми средствами ООП не возникало.

Периодически заглядываю в исходники модулей ядра и дровишек для Linux и тоже в основном все понятно в чужом коде на чистом C.

Явное и естественное желание использовать ООП возникло при обдумывании GUI оберток, где все может меняться налету, наследоваться, бегать, прыгать, скакать и масштабироваться.

В более низкоуровневой области использование ООП напрашивается при описании хитровывернутых протоколов с кучей настроек, режимов и свистелок.

Edited by BackEnd

Share this post


Link to post
Share on other sites
Полиморфизм, инкапсуляция и шаблоны дадут более компактный, простой и человекочитаемый код. В простом коде сложнее допустить ошибки, его легче поддерживать.

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

 

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

Отладка и поиск бага в такой программе то ещё "удовольствие".

 

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

 

Т.е. ООП направлен на скрытие "несущественных деталей".

А как быть если копаться в этих "деталях" и искать в них баги как раз и есть твоя работа?

А их от тебя "скрыли". Чем усложнили твою работу

Edited by Укушенный воблой

Share this post


Link to post
Share on other sites

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

метод длиннее 20 строк? надо рефакторить!

 

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

Edited by Огурцов

Share this post


Link to post
Share on other sites
Вообще, у меня сложилось впечатление, что приличное количество программистов переняли себе определенный стиль поведения, сходный с дорожными рабочими. В духе - зачем сразу делать качественные дороги, когда можно делать некачественные и потом бесконечно их ремонтировать?

На эту тему есть фейковое интервью Страуструпа, но как раз про это. :biggrin:

Если кто не видел оригинал прикола http://www.erenkrantz.com/Humor/FakeIEEESt...Interview.shtml

Перевод http://archive.is/tC8ZR

 

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this