Для цілі з дуже обмеженими ресурсами, такої як 4 КБ оперативної пам'яті, я б протестував води за допомогою деяких зразків, перш ніж докласти багато зусиль, які неможливо легко перенести назад у чисту реалізацію ANSI C.
Робоча група Embedded C ++ запропонувала стандартну підмножину мови та стандартну підмножину стандартної бібліотеки. На жаль, я загубив ці зусилля, коли журнал користувача C помер, на жаль. Схоже, у Вікіпедії є стаття , і що комітет все ще існує.
У вбудованому середовищі ви дійсно повинні бути обережними щодо розподілу пам’яті. Щоб забезпечити цю турботу, можливо, вам доведеться визначити глобального operator new()та його друзів до чогось, що навіть не може бути пов'язане, щоб ви знали, що воно не використовується. Розміщення, newз іншого боку, швидше за все, буде вашим другом, якщо його використовувати розумно разом зі стабільною схемою розподілу, гарантованою затримкою та затримкою.
Вбудовані функції не спричинять особливих проблем, якщо вони не настільки великі, що спочатку мали бути справжніми функціями. Звичайно, у макросів, які вони замінювали, була та сама проблема.
Шаблони теж можуть не створювати проблем, якщо їх екземпляр не запуститься. Для будь-якого шаблону, який ви використовуєте, перевіряйте згенерований код (на карті посилань може бути достатньо підказок), щоб переконатися, що відбулися лише ті екземпляри, які ви збиралися використовувати.
Ще одна проблема, яка може виникнути, - це сумісність з вашим налагоджувачем. Незвично, що апаратний налагоджувач, який можна використовувати інакше, має дуже обмежену підтримку взаємодії з вихідним вихідним кодом. Якщо вам ефективно потрібно налагоджувати в збірці, то цікаве назви керування C ++ може внести додаткову плутанину в завдання.
RTTI, динамічні трансляції, множинне успадкування, важкий поліморфізм та винятки - все це пов’язано з певною вартістю виконання для їх використання. Деякі з цих функцій рівні, які коштують за всю програму, якщо вони використовуються, інші просто збільшують вагу класів, які в них потребують. Дізнайтеся різницю та мудро вибирайте розширені функції з повним знанням хоча б побіжного аналізу витрат / вигод.
У невеликому вбудованому середовищі ви будете або безпосередньо підключатись до ядра реального часу, або працювати безпосередньо на апаратному забезпеченні. У будь-якому випадку вам потрібно буде переконатися, що ваш код запуску під час виконання правильно обробляє завдання запуску, що відповідають C ++. Це може бути настільки просто, як переконатися у використанні правильних параметрів компонувальника, але оскільки загальноприйнятим є прямий контроль над джерелом до точки входу при перезавантаженні, можливо, вам доведеться перевірити це, щоб переконатися, що він робить все. Наприклад, на платформі ColdFire, над якою я працював, інструменти розробника постачалися з модулем CRT0.S, який мав ініціалізатори С ++, але коментував їх. Якби я використовував його прямо з коробки, мене б спантеличили глобальні об'єкти, конструктори яких взагалі ніколи не працювали.
Крім того, у вбудованому середовищі часто потрібно ініціалізувати апаратні пристрої, перш ніж їх можна буде використовувати, а якщо немає ОС та завантажувача, то це робить ваш код. Вам потрібно буде пам’ятати, що конструктори для глобальних об’єктів запускаються до main() виклику, тому вам потрібно буде змінити локальний CRT0.S (або його еквівалент), щоб виконати таку ініціалізацію обладнання до виклику самих глобальних конструкторів. Очевидно, що вершина main()занадто пізня.