Для цели с очень ограниченным ресурсом, такой как 4 КБ ОЗУ, я бы протестировал воды с некоторыми образцами, прежде чем прилагать много усилий, которые не могут быть легко перенесены обратно в чистую реализацию ANSI C ,
Рабочая группа по Embedded C ++ предложила стандартное подмножество языка и стандартное подмножество стандартной библиотеки. К сожалению, я потерял следы этих усилий, когда умер журнал пользователя C. Похоже, что в Википедии есть статья, и комитет все еще существует.
Во встроенной среде вам действительно нужно быть осторожным с распределением памяти. Для обеспечения такой заботы вам может потребоваться определить глобальный operator new() и его друзей для чего-то, что нельзя даже связать, чтобы вы знали, что оно не используется. С другой стороны, размещение new, вероятно, будет вашим другом, если его использовать разумно вместе со стабильной, поточно-ориентированной и гарантированной задержкой схемой размещения.
Встроенные функции не вызовут особых проблем, если только они не будут достаточно большими, чтобы они должны были быть истинными функциями. Конечно, у макросов, которые они заменяли, была та же проблема.
Шаблоны тоже могут не вызывать проблем, если их создание не выходит из-под контроля. Для любого шаблона, который вы используете, проведите аудит сгенерированного кода (у карты ссылок может быть достаточно ключей), чтобы убедиться, что произошли только те экземпляры, которые вы намеревались использовать.
Еще одна проблема, которая может возникнуть, - это совместимость с вашим отладчиком. Для аппаратного отладчика, который можно использовать в других случаях, весьма обычно иметь очень ограниченную поддержку взаимодействия с исходным исходным кодом. Если вы фактически должны отлаживать сборку, то интересное искажение имен в C ++ может добавить дополнительную путаницу в задачу.
RTTI, динамическое приведение, множественное наследование, тяжелый полиморфизм и исключения - все это сопряжено с определенными затратами времени выполнения для их использования. Некоторые из этих функций имеют уровень стоимости всей программы, если они используются, другие просто увеличивают вес классов, которые в них нуждаются. Знайте разницу и выбирайте расширенные функции с полным знанием хотя бы беглого анализа затрат / выгод.
В небольшой встроенной среде вы будете либо напрямую подключаться к ядру реального времени, либо работать непосредственно на оборудовании. В любом случае вам нужно убедиться, что ваш код запуска во время выполнения правильно обрабатывает специфичные для C ++ задачи по запуску. Это может быть так же просто, как использование правильных опций компоновщика, но поскольку обычно прямой контроль над источником осуществляется с точкой входа при перезагрузке, вам может потребоваться проверить это, чтобы убедиться, что он выполняет все. Например, на платформе ColdFire, над которой я работал, инструменты dev поставлялись с модулем CRT0.S, в котором присутствовали инициализаторы C ++, но комментировались. Если бы я использовал его прямо из коробки, я был бы озадачен глобальными объектами, конструкторы которых вообще никогда не запускались.
Кроме того, во встроенной среде часто необходимо инициализировать аппаратные устройства, прежде чем их можно будет использовать, и если нет ОС и загрузчика, то это делает ваш код. Вам нужно помнить, что конструкторы для глобальных объектов запускаются до вызова main(), поэтому вам нужно будет изменить локальный CRT0.S (или его эквивалент), чтобы выполнить аппаратную инициализацию до сами глобальные конструкторы называются. Очевидно, что вершина main() слишком поздняя.