AlexandrY 2 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба Ссылка - https://habrahabr.ru/post/308550/ Наконец-то выразили словами то, что я всегда хотел сказать. Т.е. для малых встраиваемых систем на Cortex-M3..M7, или для 8-и битников подавно преимущества C++ сводятся к нулю. Поскольку в проектах для них задействовано слишком мало программистов. Нужно не меньше сотни. А большее влияние на скорость разработки оказывают параметры IDE. В частности скорость компиляции. Поскольку это определяют культуру проектов. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Grizzly 0 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба Не согласен, что именно IDE определяет скорость компиляции и тем более культуру программирования. Использование редактора, компилятора, СУВ и make без лишних сущностей в виде IDE зачастую требует большей культуры, строгости и т.д. и т.п. Но это слишком субъективно и не совсем по теме, не мог пройти мимо ;) Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 49 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба вот уж скорость компиляции для "малых встраиваемых систем" вообще не заметна должна быть. а цифры в статье высосаны непонятно из чего. и для малых встраиваемых систем какой-нибудь простенький ГУЙ, например, с плюсами, даже одним человеком, пожалуй будет веселее и писАться, и затем читаться, чем на просто С, ну пусть и на 10-20%. а писать обёртки на С++ для какого-нибудь GPIO и таймеров пожалуй действительно баловство. ну и даже если плюсы не ускоряют разработку на небольших проектах, их надо теперь отовсюду выпилить что ли и запретить, мешают они кому-то? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Grizzly 0 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба а цифры в статье высосаны непонятно из чего. Это больше всего удивило в статье. Так можно было бы не 7% написать, а любое другое... Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба Не согласен, что именно IDE определяет скорость компиляции и тем более культуру программирования. Использование редактора, компилятора, СУВ и make без лишних сущностей в виде IDE зачастую требует большей культуры, строгости и т.д. и т.п. Но это слишком субъективно и не совсем по теме, не мог пройти мимо ;) Да, наверно понятие "культура" здесь сильно многозначное, сложно вокруг него дискутировать. Но я здесь имел в виду то, как делится проект на файлы и библиотеки, какие средства отладки интегрируются в исходники и как используются. Сколько версий создается и существует одновременно, как планируется время для отладки и какие средства на неё выделяются и т.д. Строгость или дисциплина тут не при чём. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 117 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба Очень понравился комментарий: Десять программистов не сделают работу в десять раз быстрее, чем один программист, даже если говорить об одном и том же языке. Примерно на трети текста стало не интересно, я не настолько зануда.Полностью согласен. Статья - ерунда. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба вот уж скорость компиляции для "малых встраиваемых систем" вообще не заметна должна быть. Ну это уже не малые будут, а примитивные. Проект с микролинуксом компилироваться может десятки минут, .NET micro framework тоже не меньше 15 мин компилируется. Те же RTOS со всем middleware компилируются по 5 мин и дольше. Чтобы накомпилить 1 мег бинарника не меньше 10 мин надо. А в GCC и все полчаса. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quarz 0 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба Не согласен с топикстартером. А статья написана в стиле сумасшедшего бреда, обсуждают среднюю температуру по больнице. Код на С++ лучше структурирован - а значит легче для понимания. Если ваша программа занимает 1-2 экрана - не важно, на каком языке пишете, берите любой из популярных который лучше знаете. Но если это программа для прибора с датчиками, протоколами, алгоритмами и конечными автоматами - С++ будет намного эффективнее. Полиморфизм, инкапсуляция и шаблоны дадут более компактный, простой и человекочитаемый код. В простом коде сложнее допустить ошибки, его легче поддерживать. Я писал на Ассемблере и Си для PIC и Avr, а год назад свой проект под M3 переписывал на Си++. Код стал красивее :) Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба Я писал на Ассемблере и Си для PIC и Avr, а год назад свой проект под M3 переписывал на Си++. Код стал красивее :) Так не о красоте же речь. Вот гарантию даю, я скобочками, отступами, раскраской и подбором имён сделаю код на С-и красивее вашего. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
quarz 0 26 августа, 2016 Опубликовано 26 августа, 2016 · Жалоба Так не о красоте же речь. Вот гарантию даю, я скобочками, отступами, раскраской и подбором имён сделаю код на С-и красивее вашего. Кажется вы пропустили абзац в моем посте. Я не только о красоте говорил. Чем больше программа, тем эффективнее в ней будет применение высокоуровнего языка. Это - факт. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
backend 0 27 августа, 2016 Опубликовано 27 августа, 2016 (изменено) · Жалоба Код на С++ лучше структурирован - а значит легче для понимания. Думаю, сам по себе C++ не делает код структурированным. Структурированным его делает разработчик, если знает как. Потребовалось мне однажды поправить чужой проект для сравнительно небольшого устройства. Автор, вдохновленный передовыми возможностями ООП, напихал в суперкласс кучу всяких разностей, предполагая, что будет тыща версий устройств и все это когда-то кому-то пригодится. Однако предположение за 15 лет так и не оправдалось, устройство просуществовало в одном варианте со всеми избыточными наворотами кода. После прорубания через заросли исходников, выяснилось, что весь код умещается на пару читабельных экранов без нагромождений ООП. Но если это программа для прибора с датчиками, протоколами, алгоритмами и конечными автоматами - С++ будет намного эффективнее. Это скользкая оценка. Как, например, измерить эффективность языка программирования? И насколько это "намного" эффективнее? Вот гарантию даю, я скобочками, отступами, раскраской и подбором имён сделаю код на С-и красивее вашего. У меня возникают похожие мысли. Чем больше программа, тем эффективнее в ней будет применение высокоуровнего языка. Это - факт. А если на заключительном этапе разработки в базовом классе обнаружен баг и его исправление затронет все производные от него структуры с последующим затратным тестированием? Будет ли это эффективно? По поводу объемов кода... Читал я об использовании несколько лукавого критерия "количество строк кода" при оценке целесообразности применения C или C++ для конкретного проекта: - до 10 000 применять C; - от 10 000 до 100 000 возможны варианты C/C++; - от 100 000 применять C++. Мои личные ощущения в целом согласуются с таким подходом. Для написания математического ядра или эмбеддерства мои проекты не вылазили за 20 000 строк, поэтому стойкой потребности в языке с развитыми средствами ООП не возникало. Периодически заглядываю в исходники модулей ядра и дровишек для Linux и тоже в основном все понятно в чужом коде на чистом C. Явное и естественное желание использовать ООП возникло при обдумывании GUI оберток, где все может меняться налету, наследоваться, бегать, прыгать, скакать и масштабироваться. В более низкоуровневой области использование ООП напрашивается при описании хитровывернутых протоколов с кучей настроек, режимов и свистелок. Изменено 27 августа, 2016 пользователем BackEnd Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Укушенный воблой 0 27 августа, 2016 Опубликовано 27 августа, 2016 (изменено) · Жалоба Полиморфизм, инкапсуляция и шаблоны дадут более компактный, простой и человекочитаемый код. В простом коде сложнее допустить ошибки, его легче поддерживать. То что код будет компактный - это вовсе не значит что он будет более читабельный и его удобней поддерживать. Когда у тебя (а хуже когда в чужом коде, который ты поддерживаешь) куча многоэтажных (причем ПЕРЕКРЕСТНЫХ) иерархий классов, шаблонов, перегрузок и виртуальных функций, то чтобы понять какой же код на самом деле у тебя здесь работает нужно перелопатить всю иерархию и просмотреть все варианты перегрузки и проанализировать шаблоны. Отладка и поиск бага в такой программе то ещё "удовольствие". И получается, что когда нужно ДЕТАЛЬНО понять что конкретно и где у тебя вызывается (а не просто получить общее "абстрактное" представление о коде) как же работает данный код, то в страничке кода на С++ можно разбираться НЕДЕЛЮ. Т.е. ООП направлен на скрытие "несущественных деталей". А как быть если копаться в этих "деталях" и искать в них баги как раз и есть твоя работа? А их от тебя "скрыли". Чем усложнили твою работу Изменено 27 августа, 2016 пользователем Укушенный воблой Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
krux 8 27 августа, 2016 Опубликовано 27 августа, 2016 · Жалоба В современной парадигме ООП для того чтобы всё корректно наследовалось, перегружалось и пр - принято плодить много однострочных методов. метод длиннее 20 строк? надо рефакторить! В результате вместо куска алгоритма функционально на один экран, в котором разобраться - три минуты, получается 25+ методов, раскиданных по тексту черти где, и понимание сути алгоритма растягивается минут на 20. Вообще, у меня сложилось впечатление, что приличное количество программистов переняли себе определенный стиль поведения, сходный с дорожными рабочими. В духе - зачем сразу делать качественные дороги, когда можно делать некачественные и потом бесконечно их ремонтировать? Зачем сразу писать код, который будет гарантированно работать, и лишать тем самым себя стабильного заработка на среднесрочную перспективу? Ведь переключение на написание другой программы потребуется опять РАЗБИРАТЬСЯ с тем что должно быть реализовано, знакомиться с новой предметной областью. А это надо мозгами опять шевелить, а не куски методов туда-сюда копипастить. Лень. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 27 августа, 2016 Опубликовано 27 августа, 2016 (изменено) · Жалоба вот писали бы все сишники и плюшники на объект-паскале и не парили людям моск Изменено 27 августа, 2016 пользователем Огурцов Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
backend 0 27 августа, 2016 Опубликовано 27 августа, 2016 · Жалоба Вообще, у меня сложилось впечатление, что приличное количество программистов переняли себе определенный стиль поведения, сходный с дорожными рабочими. В духе - зачем сразу делать качественные дороги, когда можно делать некачественные и потом бесконечно их ремонтировать? На эту тему есть фейковое интервью Страуструпа, но как раз про это. Если кто не видел оригинал прикола http://www.erenkrantz.com/Humor/FakeIEEESt...Interview.shtml Перевод http://archive.is/tC8ZR Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться