Embedded C ++: использовать STL или нет?

Question

Я всегда был инженером по встроенному программному обеспечению, но обычно на уровне 3 или 2 стека OSI. Я на самом деле не аппаратный парень. Я обычно всегда делал телекоммуникационные продукты, обычно ручные / мобильные телефоны, что обычно означает что-то вроде процессора ARM 7.

Теперь я нахожусь в более общем встроенном мире, в небольшом стартапе, где я мог бы перейти на «не очень мощные» процессоры (есть субъективный бит) - я не могу предсказать, какие именно.

Я довольно много читал о дебатах об использовании STL в C ++ во встроенных системах, и однозначного ответа нет. Есть некоторые небольшие проблемы с переносимостью, а некоторые - с размером кода и временем выполнения, но у меня есть две основные проблемы:
1 - обработка исключений; Я до сих пор не уверен, стоит ли его использовать (см. Embedded C ++: использовать исключения или нет? )
2 - Я сильно не люблю динамическое распределение памяти во встроенных системах из-за проблем, которые он может создать. У меня обычно есть пул буферов, который статически выделяется во время компиляции и который обслуживает только буферы фиксированного размера (если нет буферов, сброс системы). STL, конечно, делает много динамического распределения.

Теперь я должен принять решение, использовать ли STL или отказаться от него - для всей компании, навсегда (речь идет о некоторых основных программах).

Каким образом я прыгаю? Супер-безопасный и потеряет большую часть того, что составляет C ++ (то есть, это больше, чем просто определение языка) и может столкнуться с проблемами позже или придется добавить много обработки исключений и, возможно, какой-то другой код сейчас?

У меня возникает соблазн просто пойти с Boost , но 1) я не уверен, будет ли он портировать на каждый встроенный процессор, который я мог бы использовать, и 2) на их сайте они говорят, что они не Не гарантирую / не рекомендую определенные его части для встраиваемых систем (особенно для FSM, что кажется странным). Если я пойду на повышение, и мы обнаружим проблему позже ....

Answer 1

Самая большая проблема с STL во встроенных системах - это проблема выделения памяти (которая, как вы сказали, вызывает много проблем).

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

Что касается вопроса об исключениях, я бы туда не пошел. Исключения - это серьезное замедление вашего кода, поскольку они заставляют каждый отдельный блок ({ }) иметь код до и после, что позволяет перехватывать исключение и уничтожать любые содержащиеся в нем объекты. У меня нет точных данных по этому вопросу, но каждый раз, когда я сталкивался с этой проблемой, я видел убедительные доказательства огромного замедления, вызванного использованием исключений.

Edit:
Поскольку многие люди писали комментарии о том, что обработка исключений не медленнее, я решил добавить эту небольшую заметку (спасибо тем, кто написал это в комментариях, я подумал, что было бы хорошо добавить это здесь).

Причина, по которой обработка исключений замедляет ваш код, заключается в том, что компилятор должен удостовериться, что каждый блок ({}), от места, где выбрасывается исключение, до места, с которым он обрабатывается, должен освобождать любые объекты внутри него. Это код, который добавляется к каждому блоку, независимо от того, генерирует ли кто-либо исключение или нет (поскольку компилятор не может сказать во время компиляции, будет ли этот блок частью "цепочки" исключений).

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