По-моему, вполне понятно о чем идет речь. Заявляется (голословно), что С++ язык медленный, а С и, уж конечно, ASM, намного быстрее. Посему, задача изначально проектируется не на С++. Ровно про это писал Александреску со-товарищи, а именно, сначала сделайте работоспособное решение, а потом, изучайте узкие места и их оптимизируете. Вроде я "мастерам" не противоречу, говоря о "преждевременной оптимизации"-

Вы опять с этим Александреску с его обобщенно-шаблонно-абстрактным программированием .
Нам такие товарищи эмбеддерам совсем НЕ товарищи. Думать о построении системы и узких местах нужно СРАЗУ, а не потом рассматривая что такое выросло и как "оптимизировать" сие ЗАПЛАТКАМИ. Все узкие места должны быть ИЗВЕСТНЫ на этапе проектирования, и сделаны ОЦЕНКИ критичности этих мест до того, как будет написана левой ногой кучи кода.

Ну ладно. Александреску нам не авторитет. Мне тоже не все его мысли и рецепты нравятся, хотя встречаются и очень изящные решения. Посмотрим с другой стороны. Имеем в начале работы процессор, компилятор и стандартную библиотеку. Начинаем работать? Начинаем. Прикидываем все, где чего и как по-лучше написать. Сделали. И вдруг (или не вдруг) натыкаемся на то, что стандартная memcpy полная г...о (на форуме мы это неоднократно обсуждали), а мы ее пользуем в хвост и в гриву. Затем выясняется, что и memset такая же. А потом понимаем, что вся куча написана через жо...у. Мы про это тоже СРАЗУ должны были знать на начальном этапе проектирования? Откуда? Нам фирма-изготовитель компилятора "любезно" рассказала?

Вы всегда можете предсказать какой именно алгоритм сортировки окажется самым быстрым на вашем конкретном типе данных? Ой ли.

С другой стороны, может и с этими хреновыми (не оптимальными) функциями все вполне бы катило и заказчика устраивало? Мы тогда жили бы себе в спокойном чувстве полного самоудовлетворения и над всей этой ерундой и не задумывались.

Резюме (мое личное, может и неправильное) - невозможно все заранее предусмотреть (кое что можно), хотя бы из-за ограниченности собственных временнЫх возможностей и сил. Проект всегда итерационен (почти).

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

Именно так и есть, обычно все библиотеки САМ перекопилируешь-выкидывая оттуда
все ненужное и исправляя ихние ошибки.
Что в этом неправильного?

Забыли главное - голову на плечах и опыт отличный от нуля. Без этих двух вещей получаем воинствуещего ламера inventor .

Подход а-ля Александреску характерен для научных работ - давайте на бумаге/модели получим, хоть какой-то результат и потом подумаем, что дальше делать. У инженеров в сложных случаях тоже есть понятие НИОКР, но это именно заранее запланированный этап.

Это само собой подразумевалось. Однако, при переходе на новый процессор+компилятор всегда есть определенная доля неизведанности, понимание которой приходит не СРАЗУ, а по мере работы над проектом.

Потом, мне кажется, спор возник из-за наличия двух принципиально различных типов проектов. Первые, по типу обучения в вузе "зазубрил/сдал/забыл", а вторые - большие проекты, пишущиеся и развивающиеся годами. Коллеги работают в разных типах проектов, отсюда и разное видение проблем.

На новый процессор - для этого существуют отладочные платы - купил, попробовал, в том числе и принципиально узки места по железу/софту, осознал...
С компиляторами все еще проще - они достаточно все одинаково хороши и обычно кроссплатформенны, посему, как правило, компилятор уже достаточно знаком.
Исключения встречаются, но они скорее всего уже именно исключения, если необходимо вдруг наконец-то заставить работать что-то старое неведомо кем сделанное. И тогда имеем какой-нибудь достаточно ущербный контроллер и такой-же замерший в прошлом компилятор. Я в прошлом году дважды с таким сталкивался - PIC16 + Hi-Tech C компилятор и M8C + ImageCraft. Это дополнительно создает некоторые хлопоты. Но это был такой прыжок в прошлое. Нехарактерный.

Категорически нет. Проблема просто у уровне знаний - ниже плинтуса, или выше.

Согласитесь,что проект <4Kb и проект >1Mb несколько отличаются. И технологии при их реализации тоже.

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

Да, но не надо переживать о нескольких лишних байтах/циклах там, где это совершенно некритично.
Некоторые в ужасе хватаются за голову, видя в контроллерном проекте float.
Ну а что такого? Если скорость всех расчётов на порядки выше, чем скорость поступления сэмплов с АЦП.
Вот это видимо и имелось в виду.
Не надо пытаться заоптимизировать всё до смерти без насущной необходимости.
Иметь представление об узких местах и проектировать с их учётом - надо.

А про оптимизацию, по-моему, Макконнел рассуждал в "совершенном коде".
У него было там что-то типа "мысли об оптимизации могут совершенно заблокировать разработку проекта. "

Вот нашёл, цитата из книги:

И где тут пример? Привели какие-то общие фразы, дескать, тут быстрее, тут медленее, а С++ тут вообще в пролёте. Где аргументы? Где доказательства? Реальный пример давайте. Например, вот написали протокол обмена по UART на С++, оказалось в два раза медленнее, чем на С. Вот и давайте оба варианта (на С и на С++) в студию. Это будет пример, который можно обсуждать.




Насчёт Александреску вынужден не согласиться. У него показаны приёмы, как сделать написание кода более удобным и безопасным. Это, конечно, требует труда вникать (например, списки типов я так до конца и не вкурил - хоть и интересно, но актуальности пока нет и не предвидится, хотя имею в виду). Но у него помимо "тяжёлых" вещей вроде разработки на основе стратегий, немало просто полезных фишек вроде "распознавания конвертируемости и наследования на этапе компиляции". Конечно, подобные приёмы возникли от недостатка соответствующих средств в самом языке, но само решение очень красиво и, главное, в отличие от typeof(), выполняется на этапе компиляции. Или его менеджер памяти, который оптимизирован (скорость и компактность) для работы небольшими (десятки байт) объектами. Для AVR, конечно, не пойдёт, но на каком-нить АРМе уже вполне может оказаться кстати.

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

Согласен, хотя я пока ниасилил. Выглядит как книга магических заклинаний: завораживает, но ничего не понятно! Остаётся пользоваться готовыми рецептами, самому готовить ещё учиться и ещё два раза.

Я не об этом - он реально занимается решением ДРУГИХ задач и выхватывать из его книг какие-то слова, например, о вреде преждевременной оптимизации и поминать их всуе, как минимум, не корректно.

Золотые слова - подпишусь под каждым. Только вот К ЖУТЧАЙШЕМУ моему сожалению толпы эмбеддерщиков об оптимизации на верхних уровнях думают с трудом . Зато по рассуждать о том что на десяти командах они на АSM обгонят компилятор это всегда готовы . А услышав слова о вреде преждевременной оптимизации поснимают галочки где-нибудь в IDE и скажут, что Александреску с Макконнелом так велят .
Умение оптимизировать на верхних уровнях определяется в том числе и инструментальными средствами которые человек освоил. Одно дело, когда человек пошел от сохи железа и постиг программирование в кодах (на самом деле он считает, что пишет, на ASM, но реально это настолько минималистичное использование даже ASM, что это практически кодирование ). Другое, когда уже понимает и имеет успешный опыт, например, в C++. Это другие горизонты, другое понимание и другие возможности.

Мне тоже не всё понятно было (пока её только на разок прошёл), но кое-что уже в кассу. Например, подсмотрел приём, который он там реализует для стратегий:

Т.е. шаблон, позволяющий генерировать реализацию с выбором базы для неё. Простая, в общем-то, штука, но как-то само в голову не пришло. Эту вещь реально поюзал.

Или реализация класса Conversion (п.2.7). Довольно простое и изящное решение на основе свойств оператора sizeof(). Пока применить не пришлось, но имею в виду. Очень нравится незамутнённый нестандартный взгляд на привычные, уже набившие оскомину вещи. Что ни говори, а Александреску молодец, и каждый при желании может там найти для себя что-то полезное и интересное.

Блин ну ладно еще асм с с сравнивать, это еще как бы куда ни шло, хотя с оговоркой - кто писал си и кто писал асм. Но С++ с С противопоставлять - вы понимаете что что С++ принципиально не отличается от С?