Да согласен, придется только поменять все методы класса Led на const, что собетвенно и правильно, так как поля класса не меняются и эти 56 байт улетят в ПЗУ, освободив стек. Хорошее замечание.
Ну впринципе вообще глобальная переменная это вред. Static можно, но какая рзаница? ОЗУ все равно отъест, а где не имеет значения в стеке или сегменте данных (адрессное пространстров одно, это же не микрочип 16 где стек аппаратный). Единственное, контроллировать стек надо будет, но линкер выдает его максимальный размер, поэтому с моей точки зрения, вообще без разницы.
не понял вопроса, вы имеете ввиду, что можно, например, сделать включение и выключение всех светодидов маской?
GPIOC->ODR |= ALLLEDS_MASK;
GPIOC->ODR &=~ ALLLEDS_MASK;
Но порты же разные вообще А и С, к ним впринципе одномоментно нельзя маски применить.
Или сделать массив из битов портов, используя битбендинг и по нему лазить, но в чем тогда разница, между обыччным массивом?
На 8, — 256 кБайта памяти программ и 4 — 20 кБ ОЗУ, он никогда не придет. Миниатюрным датчикам и низкопотребляющим устройствам это не грозит тоже. А вся промышленность сидит именно на этом. Все упирается в потребление и цену, зачем мне быстрый навороченный микро, который стоит 7 баксов, но с возможностью Джава, если то же само можно сделать на 1 баксовом? При объемах в 30 000 скажем датчиках в год (а к слову, средний объем датчиков температуры у какого-нибудь Элемера) получим 180 000 долларов экономии! А если взять конторы покрупнее, то выгода может быть и под миллион долларов.
Исключения сразу значительно увеличит размер кода, так как добавится таблица с информацией о том где исключение было поднято и где искать его обработчик и сам механизм поиска обработчика исключения тоже будет в коде. Ну и медленно это все будет… на 1 Мгц то.
Наследование, не показал согласен, но оно вообще когда не добавит, если вирутальные функции не использовать. Можно обойтись же без shared_ptr. Я тут старался показать, что код на намного С++ лаконичнее, и размер такой же. и это не просто Си с использование соврменного синтаксиса, так как на Си такое будет занимать больше места, я там написал, что можно структры использовать и указатели на функции, но это сразу + к размеру.
Про std, см комментарий от NightShad0w, при ключенной оптимизации все работает ОК. habrahabr.ru/post/347980/#comment_10646698. Проверил на IAR, тоже код такой же. Поэтому её использовать можно, но не безздумно. unique_ptr например запросто, он ничего не добавит, а вот shared_ptr нет, он сразу добавит много накладных, хотя все зависит от задачи, если вы на Си будете решать, ту же задачу, что решает во многих случая shared_ptr, то возможно и кода будет больше.
) конечно, можно было использовать просто массивы или std::array. Vector слишком громоздкий, и юзает динамически выделяемую память. Сразу появляется куча, за которой следить нужно… Лучше динамически создаваемые объекты вообще не использовать.
Я, согласен, что это топорный пример, но я там написал, что это очень синтетический тест, его конечно можно улучшить, но я хотел показать, что если писать в лоб, примерно в одном стиле, то можно получить такой вот результат.
Оптимизация включена, при включенной код не имеет смысла, все вычисляется на этапе компиляции. Тут показано, что в общем случае for с обходом через итератор преобразуется в более эффективный код.
Разница в том что указатель изменяемый, его можно забыть про инициализировать, можно нечаянно поменять. Таких примеров предостаточно. Для этого в срр и придуманы были ссылки, и умные указатели, чтобы такие проблемы и закрывать.
GPIOC->ODR |= ALLLEDS_MASK;
GPIOC->ODR &=~ ALLLEDS_MASK;
Но порты же разные вообще А и С, к ним впринципе одномоментно нельзя маски применить.
Или сделать массив из битов портов, используя битбендинг и по нему лазить, но в чем тогда разница, между обыччным массивом?
Про std, см комментарий от NightShad0w, при ключенной оптимизации все работает ОК.
habrahabr.ru/post/347980/#comment_10646698. Проверил на IAR, тоже код такой же. Поэтому её использовать можно, но не безздумно. unique_ptr например запросто, он ничего не добавит, а вот shared_ptr нет, он сразу добавит много накладных, хотя все зависит от задачи, если вы на Си будете решать, ту же задачу, что решает во многих случая shared_ptr, то возможно и кода будет больше.
) конечно, можно было использовать просто массивы или std::array. Vector слишком громоздкий, и юзает динамически выделяемую память. Сразу появляется куча, за которой следить нужно… Лучше динамически создаваемые объекты вообще не использовать.
Оптимизация включена, при включенной код не имеет смысла, все вычисляется на этапе компиляции. Тут показано, что в общем случае for с обходом через итератор преобразуется в более эффективный код.
Разница в том что указатель изменяемый, его можно забыть про инициализировать, можно нечаянно поменять. Таких примеров предостаточно. Для этого в срр и придуманы были ссылки, и умные указатели, чтобы такие проблемы и закрывать.
Есть такой, на этой же плате с графическим индикатором и блутузом, но в статью не влезет.
Он не UB, но при включенной оптимизации, размер действительно 0. Можно сделать ввиде отдельной функции.