Конференция C++ Russia, 27-28 февраля 2015, Москва, а также почему Эмбеддеру это может быть интересно.

Мероприятия
Касперски Лабс, ВиваСолюшнс и еще куча других веселых ребят в последние дни февраля 2015 года в городе Москва организуют конференцию по C++.


Я знаю, что C++ у Эмбеддеров не в почете (что, кстати, весьма зазря), однако кому-то информация поста может быть полезной.

Во-первых, ссылка на мероприятие:
http://meetingcpp.ru/

Во-вторых, немного ифнормации о том, почему для эмбеддера C++ это НЕ плохо.

Скопирую свой комментарий по поводу C++, дабы он не улетел в анналы истории:
С++ для эмбеддера это:
0. Пространства имен. Придумывать префиксы для каждой функции в С хорошо, но еще лучше — надеяться что они не пересекаются. В С++ это решается с помощью namespace и классов. И когда ты ставишь точку, автодополнение дает тебе список ТОЛЬКО того, что тебе можно. Это позволяет писать разные модули с одинаковыми названиями функций, всегда выбирая тот модуль, который нужен.
1. Разделение уровней доступа — если у меня и есть какая-то внутренняя переменная, то в С иногда сложно избежать соблазна не поставить костыль. В C++ внутри класса я просто делаю ее private. Отсюда — приходится продумывать архитектуру приложения — на поддержке кода это очень пригодится.
2. Перегрузка функций и шаблоны. Я просто обожаю в С продумывать функции для всех возможных типов данных. И для uint8_t и для int8_t и 16_t и 32_t и float и т.д. и т.п. В C++ это решается с помощью простых шаблонов. Стоимость этого шаблона будет равна стоимости нескольких функций в С, за исключением того, что все функции за тебя продумает компилятор.
3. Безопасное кастование! Привычное нам (type)var в С является небезопасным преобразованием типов и только в самых упоротых случаях уронит компиляцию. Во всех остальных случаях кастование пройдет. Но не факт что успешно. Сравните C++ static_cast и reinterpret_cast(аналог С-шных скобочек (type_t)var). Мне иногда попадаются просто фееричные преобразования типов в разгребаемом коде, когда они неявно перегоняются из знакового в беззнаковый, из short в long да по нескольку раз… static_cast в отличие от reinterpret_cast в неподобающих случаях вызовет ошибку компиляции и заставит хорошенько подумать. Причем в С ошибка может быть обнаружена только с помощью статического анализа кода(PVS Studio справляется, Clang и cppcheck — как правило нет). Ну может быть он ругнется на сравнение знаковой и беззнаковой переменной в if или в переходе от double к float… или вы скормили const в не cosnt…
4.Перечисляемые типы. Дефайны — зло. Есть тысяча и один кейсов, когда они могут привести к некоторым проблемам, ОСОБЕННО!!! при отсутствии пространства имен. Вы уверены, что своим дефайном вы ничего не переопределили? Или, например, не включили какую-нибудь опцию вида #if defined(FOO)? В том или ином виде enum есть со времен ANSI C, Classname.enum таки гораздо функциональнее.
5. и т.д.

Конечно, С++ для эмбеддера имеет свои особенности:
1. Операторы new и delete — зло. настоятельно не рекомендуется использовать динамическую аллокацию на устройствах, где:
а. Наполовину реализованная поддержка
б. У вас и так мало ОЗУ чтобы рисковать. Не бойтесь динамического выделения памяти на устройствах где ее больше пары килобайт
PS: впрочем, гораздо сложнее найти компилятор для AVR или MSP430, где они поддерживаются по умолчанию (а не через криво-написанные заголовочники как это сделано в Arduino), чем сломать с их помощью что-то.
2. STL зло. Наполовину. Там есть замечательные функции сортировки, поиска, реализации тех или иных алгоритмов… Если вы думаете, что сможете написать эффективнее чем там — удачи. Но есть там и страшные шаблоны типа vectors или lists, соблазн использовать которые необычайно велик — компьютерные приложения пишу только с их помощью, расплачиваясь потребляемой памятью (да кто ее считает), но, опять же, не скоростью исполнения программы.
3. Наследование, полиморфизм — это то, что имеет малую стоимость, но позволяет делать сложные вещи простыми инструментами. Сейчас запиливаю световой будильник на avr C++, да так увлекся, что написал целое ядро новой менюОС на С++ :) где сплошное наследование и абстракция(старую МенюОС использую все 4 года уже в десятке разных проектов, каждый раз переписывая одни и те же файлы. надоело, в общем).
4. Абстрактные классы, а, вернее, чисто виртуальные функции (virtual void foo() = 0;)- зло. В противном случае приходится работать с vtable, где есть шанс упустить важные исключения. Если в интерфейсе класса есть функции, которые в базовом классе не используются, но могут пригодиться в наследуемом, я пишу virtual void(foo){return;}; и не переживаю за пару потерянных байт на аллокацию.

Ну и напоследок, несколько ссылок с полезной на мой взгляд информацией:
Technical report on C++ performance
Using C++ Efficiently In Embedded Applications
A guide to C++ for C programmers
Многие любят ссылаться на эту книгу, хотя я ее не читал:
Software Engineering for Embedded Systems

3 комментария

avatar
1. Операторы new и delete — зло. настоятельно не рекомендуется использовать динамическую аллокацию на устройствах, где:
а. Наполовину реализованная поддержка
На самом деле тут — как организуешь. Можно сделать, чтобы память только выделялась, но не удалялась. Часто этого-достаточно. Можно сделать выделение фиксирвоанными блоками — тогда не будет утечек и все быстро будет работать.

Вообщем, куча — зло в эмбеде только в классическом своем понимании.
avatar
Да, я про дефолтные вариации компиляторов. Свои костыли, конечно же, приятнее :)
Ведь с одной стороны, зло надо правильно побеждать :)
С одной стороны Зло отстрелит тебе ногу дробовиком по колено при первой же возможности…
avatar
Кроме того, использование операторов new и delete приведет к переносу в память МК немаленького программного кода, реализующего их функционал. Скорее всего та-же ситуация с stl, например с контейнерами.
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.