Чего вдруг компилятор должен показывать статистику по стеку? Он там вообще динамический, да и какая разница сколько на него ушло, если в С уйдет столько же?[/uquote]
С чего бы вдруг? В большинстве проектов именно стек занимает 80-90% SRAM, а вовсе не статические переменные, кои легко контролируются и на C и на C++. Я не зря выше писал, что динамическое распределение памяти я, обычно, вообще отключаю, чтобы не тратить память даже на его инициализацию. Например, на SDCC у меня среда С вообще ни одного байта оперативки не потребляет! Статические переменные есть только те, которые я создал. Обычно, это несколько десятков байт и почти всегда с битовыми полями, ну пусть даже сотня. Остальное - под стек с жестким контролем. Если можно не передавать указатель вместо байта - именно так и делаю. Ну не реализуете Вы на C++ такое, если не погрязнете в изучении ассемблерного листинга, анализируя, где компилятор сожрал стек.
И ради чего этот гимморой, если задачу можно решить совершенно прозрачно и просто без него? Ну сделаете Вы, например, инициализацию массива c упакованным RLE битмапом через такое доставание левой ногой правое ухо. Я же тоже самое делаю на Perl, формируя включаемый исходный файл, при этом легко контролируя все этапы данного процесса.Reflector писал(а):Но если параллельно создать такую-же функцию transformToPins2(), убрать constexpr, добавить _noinline_ и присвоить результат обычной переменной, то все замечательно отлаживается:
Я писал про нормальные, с флешем и ARM ядром. 
[/uquote]
