Синглтон, размещающий объекты в ROM и статические переменные(С++ на примере микроконтроллера Cortex M4)

Давайте с терминами разберемся.
1. Компилятор не может ничего в ROM положить, потому что он может раскидать только по секциям. Секции по адресам раскидывает линкер, поэтому, если вы в настройках линкера сказали, что секция помеченная атрибутом .readonly должна лежать в ROM, все ваши readonly переменные будут лежать в ROM. Как бы предполагается, что в микроконтроллере с flash как раз так линкер и настроен. Конечно никто вам не запрещает специально настроить линкер, на то, чтобы все было RAM, даже код…
2. сonstexpr выражение, а в нашем случае constexpr static T instance{T()}, ни что иное, как сonstexpr выражение, может быть таким, пока не встретит там кучу всего перечислено в стандарте, но я приведу часть:

this (8.1.2), except in a constexpr function or a constexpr constructor that is being evaluated as part of e;
(2.2) — an invocation of a function other than a constexpr constructor for a literal class, a constexpr function,or an implicit invocation of a trivial destructor (15.4) [ Note: Overload resolution (16.3) is applied as usual — end note ];
(2.3) — an invocation of an undefined constexpr function or an undefined constexpr constructor;
(2.4) — an invocation of an instantiated constexpr function or constexpr constructor that fails to satisfy the requirements for a constexpr function or constexpr constructor (10.1.5);
(2.6) — an operation that would have undefined behavior as specified in Clauses 4 through 19 of this International Standard [ Note: including, for example, signed integer overflow (Clause 8), certain pointer arithmetic (8.7), division by zero (8.6), or certain shift operations (8.8) — end note ];
[Example:

int x; // not constant
struct A {
constexpr A(bool b) : m(b?42:x) { }
int m;
};
constexpr int v = A(true).m; // OK: constructor call initializes m with the value 42
constexpr int w = A(false).m; // ERROR: initializer for m is x, which is non-constant
constexpr int f1(int k) {
constexpr int x = k; // ERROR: x is not initialized by a constant expression
// because lifetime of k began outside the initializer of x
return x;

}

Т.е. как только встречается одно из этих условий, компилятор должен выдать ошибку, что ваше выражение не может быть constexpr

3. Для constexpr функций и конструктор есть отдельный раздел в стандарте и действительно нельзя определить является ли функция или конструктор constexpr или нет. Про это и был разговор со знающим человеком
4. Знающий человек Valdaros, правильно указал, на то, что объявленный constexpr конструктор может таковым не считаться, по причине того, что можно изменить const-qualified объект, и я привел пример с конструктором в конце прошлой статьи.
5. Но как только мы объявили constexpr static T instance{T()} и при этом у объекта T конструктор не соответствует пункту (2.4), наше выражение не может считаться constexpr и поэтому компилятор выдает ошибку.

Это и есть 100% гарантия того, что объект попадает в секцию помеченную .readonly, а если она в настройках линкера настроена на ROM, то и в ROM.
И это не «рекомендация» — это гарантировано стандартом.
Еще раз constexpr конструктор не гарантирует статическую инициализацию, что и было указано знающим человеком. А вот constexpr выражение написанное вами, не могущее на самом деле им быть, должно восприниматься компилятором как ошибка, он вам должен про об сообщить, что в данном методе и обыгрывается.

Ответил вам в личку…

Спасибо, за столь длинный ответ…
Таблица из МЭК 61508-7. Как вы видите из таблицы С++ и Си не рекомендованы к использованию без специальных средств проверки. А рекомендован Ada.
Я и не рассматривал Linux, потому что вообще считаю, что Linux это уже никакой не embedded. Я рассматриваю что-то типа максимум, софт использующий РТОС, типа FreeRTOS.
Линукс писался на Си, потому что в то время, действительно С++ не был столь эффективен и самое эффективное можно было писать только на Си, ну не считая ассемблера.
Архитектура ПО везде одинаковая, многослойная… и то, что я вам сказал, является ни чем иным, как бизнес логикой.
Как это не удивительно для вас, но во встроенном ПО тоже рисуют архитектуру, потому что без неё вы не получите ни одного сертификата надежности.
И да я имею ввиду только

тот же контроллер Cortex-M3, или подобный, который есть в каждом мобильном устройстве и который управляет всей системой питания и тактирования девайса

И совершенно верно вы сказали, про цену ошибки. Поэтому чтобы этого не допустить и делают
А также добиваются отсутствия ошибок с помощью процесса разработки, Требования-архитектура-код-статический анализатор-юни тесты-смок тесты-системные тесты.
Часть отвечающая за аппаратуру вообще в таком процессу описывается в специальном документе (как настроить порты, регистры периферии, микросхемы АЦП, модема и так далле), документ делают программисты вместе с электронщиками и это делается до разработки ПО, это входит в спецификацию, все что нужно дальше сделать это настроить все в соответствии с документом, что там такого заумного и сверхъестественного, что надо знать только ембедд программисту, я не понимаю… мало того, я могу вас уверить, что в большинстве случаев, после настройки в соответствии с этим документов, даже отладка не нужна. Проблемы бывают, если например, программист плохо прочитал все ерраты, и не учёл важные моменты, но в большинстве случаев все работает с первого раза. (У нас был момент связанный с AVR, когда, мы использовали, как было написано в errate не задействованный бит регистра, ну т.е его настройка ни на что не влияла, а Атмел взял и выпустили новую ревизию микроконтроллера и он стал отвечать за перевод АЦП на пониженное потребление на низкой частоте). Т.е. у нас наши прототипы на предыдущей ревизии работали хорошо, потому что настройка этого бита ничего не давала, а как только пришла новая ревизия, показания АЦП стали неверными, и мы понять ничего не могли. Вот тут и пришлось делать отладку… Но это чистый косяк программистов, которые еррату сквозь пальцы читали и потом еще на peer review проглядели этот момент.

А классы и шаблоны позволяют лучше понять код, и проследить связь архитектуры с кодом, потому что она линейная. Вы можете в принципе из UML сгенерить заготовку класса, а уж обратно и подавно. А вот как описать идею Сишного callback передающегося в функцию простым рисунком?

Мы и занимается как раз разработкой надежного ПО, чтобы не было

ошибок потенциально приводящих к зависанию и перезагрузке, или просто крэшит проток выполнения и опять перезагрузка ватчдогом

Советую этот МЭК прочитать, там описаны методики обнаружения всех этих ошибок и практики программирования для того, чтобы этих ошибок не допускать.
И это в первую очередь касается встроенного ПО
Я вас уверяю, плюсы сейчас можно использовать эффективнее Си (как по размеру кода, так и по скорости и качеству разработки), при грамотном подходе.

на cm4 вполне можно (не на всех, а где флэша 256к+), а на cm0, всяких тини13 и MSP430 как?

Я действительно пробовал ООП на МК и было это много лет назад, с тех пор ARM GCC стал менее глючным (2018q4 все равно нельзя использовать, таращит его).

Можно прямо ООП с виртуальным наследование не использовать, если нужно прямо сильно экономить, а полностью на шаблонах все сделать. Но для читабельности лучше делать понятно при использовании. Можно и не заморачиваться этим витуальные функции. Конструкторы копирования обычно не используются, для микроконтроллера точно :) В синглтоне только, разве что:) С другой стороны, конструктор это просто обычный метод, который вызывается сам в момент создания объекта для его инициализации. Туда можно засунуть много чего, например, настройку первичную порта и так далее… Соответственно конструктор копирования вызывается в момент копирования объекта… Т.е. не сложнее чем вызывать метод, только надо знать, что он сам вызывается при определенных операциях :)
Если подходить шаблон как к скриптовому языку, который может на этапе компиляции, что-то сделать с вашим кодом, и преобразовать его в что-то немного другое, удобное для использование. Сичтайте, что вам надо скрипт на Phyton написали, для того, чтобы из данных генерить заголовочники. А зачем вам Phyton, если это можно сделать с помощью самого языка и компилятора?
Умные указателя, итераторы — все сделано для того, чтобы в коде не допустить ошибку, они за вас думают, делают так, чтобы если вы создали объект, он не забыл очистить память при очистке… Т.е. по сути это в помощь вам… вам меньше надо париться и меньше деталей в голове держать, сконцентрироваться на самой задаче, а не на том, как не допустить ошибку.

Видимо вам не приходилось делать, например, медианный фильтр для фильтрации показаний датчиков.