Использование C ++ во встроенных системах

Question

Каких особенностей C ++ следует избегать во встроенных системах?

Пожалуйста, классифицируйте ответ по причине, такой как:

• использование памяти
• размер кода
• Скорость
• Портативность

РЕДАКТИРОВАТЬ: позволяет использовать ARM7TDMI с оперативной памятью 64 КБ в качестве цели для контроля объема ответов.

Answer 1

RTTI и обработка исключений:

• Увеличивает размер кода
• Снижает производительность
• Часто можно заменить более дешевыми механизмами или более совершенным программным обеспечением.

Шаблоны:

• будьте осторожны с ними, если размер кода является проблемой. Если ваш целевой ЦП не имеет или имеет очень маленький кэш инструкций, это также может снизить производительность. (шаблоны, как правило, раздувают код, если используются без заботы). Ото умное метапрограммирование может также уменьшить размер кода. На него нет однозначного ответа.

Виртуальные функции и наследование:

• Это хорошо для меня. Я пишу почти весь свой встроенный код на C. Это не мешает мне использовать таблицы указателей на функции для имитации виртуальных функций. Они никогда не становились проблемой производительности.

Answer 2

Избегание определенных функций всегда должно основываться на количественном анализе поведения вашего программного обеспечения на вашем оборудовании с выбранным выбранным набором инструментов под ограничения вашего домена влекут за собой. Существует много общепринятых «нехорошо» в разработке C ++, основанных на суевериях и древней истории, а не на твердых данных. К сожалению, это часто приводит к написанию большого количества дополнительного обходного кода, чтобы избежать использования функций, с которыми у кого-то когда-то были проблемы.

Answer 3

Исключения, вероятно, будут самым распространенным ответом того, чего следует избегать. Большинство реализаций имеют довольно большую стоимость статической памяти или стоимость оперативной памяти. Они также, как правило, усложняют гарантии в реальном времени.

Посмотрите здесь , чтобы найти довольно хороший пример стандарта кодирования, написанного для встроенного c ++.

Answer 4

Документ " Информационные технологии - Программирование языки, их окружение и системные программные интерфейсы - Технические «Отчет о производительности C ++ » также содержит полезную информацию о программировании на C ++ для встроенного устройства.

Answer 5

Это интересное прочтение для Обоснования в начале Embedded C ++ standrard

См. Эту статью также на EC ++.

Embedded C ++ std был правильным подмножеством C ++, то есть он не имеет дополнений. Следующие языковые функции были удалены:

• множественное наследование
• Виртуальные базовые классы
• Информация о типе времени выполнения (typeid)
• Новые приведения в стиле (static_cast, dynamic_cast, reinterpret_cast и const_cast)
• Спецификатор изменяемого типа
• Пространства имен
• Исключения
• Шаблоны

На вики-странице 1032 * отмечается, что Бьярн Страуструп говорит (о стандарте EC ++): "Насколько я знаю, EC ++ мертв (2004), и если нет, то это должно «. Страуструп продолжает рекомендовать документ , на который ссылается ответ Пракаша.

Answer 6

При использовании ARM7 и предположении, что у вас нет внешнего MMU, проблемы с динамическим распределением памяти могут быть сложнее отлаживать. Я бы добавил «разумное использование new / delete / free / malloc» в список рекомендаций.

Answer 7

Если вы используете ARM7TDMI, избегайте обращения к памяти без выравнивания любой ценой .

Базовое ядро ​​ARM7TDMI не имеет проверки выравнивания и будет возвращать повернутые данные, когда вы выполняете чтение без выравнивания. В некоторых реализациях есть дополнительные схемы для вызова исключения ABORT, но если у вас нет одной из этих реализаций, поиск ошибок из-за невыровненного доступа очень болезнен.

Пример:

const char x[] = "ARM7TDMI";
unsigned int y = *reinterpret_cast<const unsigned int*>(&x[3]);
printf("%c%c%c%c\n", y, y>>8, y>>16, y>>24);

• На процессоре x86 / x64 выводится «7TDM».
• На процессоре SPARC это сбрасывает ядро ​​с ошибкой шины.
• На процессоре ARM7TDMI это могло бы напечатать что-то вроде "7ARM" или "ITDM", предполагая, что переменная "x" выровнена на 32-битной границе (которая зависит от того, где находится "x" и какие параметры компилятора используются и т. д.), и вы используете режим с прямым порядком байтов. Это неопределенное поведение, но гарантированно не будет работать так, как вы хотите.

Answer 8

В большинстве систем вы не хотите использовать new / delete , если вы не переопределили их своей собственной реализацией, которая извлекает из вашей собственной управляемой кучи. Да, это будет работать, но вы имеете дело с системой с ограниченным объемом памяти.

Answer 9

Используя как компилятор GCC ARM, так и собственный SDT ARM, я получил бы следующие комментарии:

• ARM SDT производит крепче, быстрее код, но стоит очень дорого (> Eur5k за место!). На моей предыдущей работе мы использовал этот компилятор и все было в порядке.

• Инструменты GCC ARM работают очень хорошо хотя и это то, что я использую самостоятельно проекты (GBA / DS).

• Используйте режим «большого пальца», поскольку это уменьшает размер кода значительно. В 16-битных вариантах шины ARM (таких как GBA) также есть преимущество в скорости.

• 64k серьезно мало для C ++ развитие. Я бы использовал C & Assembler в этой среде.

На такой маленькой платформе вы должны быть осторожны с использованием стека. Избегайте рекурсии, больших автоматических (локальных) структур данных и т. Д. Использование кучи также будет проблемой (new, malloc и т. Д.). C даст вам больше контроля над этими проблемами.

Answer 10

Я бы не сказал, что есть жесткое и быстрое правило для этого; это сильно зависит от вашего приложения. Встраиваемые системы обычно:

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

Как и в случае любой другой разработки, вы должны сбалансировать все упомянутые вами пункты с требованиями, которые вы получили / получили.