Мы обсуждаем конкретный код вычисления среднего значения массива или написание компилятора с целевой архитектурой, у которой 32 байта RAM и килобайт FLASH?
Если про конкретный код, то он не представляет никаких проблем и любой компилятор спокойно выдаст оптимальный по размеру/скорости (в зависимости от флагов) код. И вообще любой код, который не далеко ушёл от чистого C, тоже не будет представлять проблем.
Если же про 32 байта RAM, то проблемы будут начиная с виртуальных методов (32 байта RAM очень быстро будут съедены таблицами виртуальных методов и лишними указателями) и прочего. Теоретически, вполне можно и это всё тоже оптимизировать (на таком микроконтроллере никто же не будет ничего подгружать динамически, поэтому вполне можно на этапе компиляции избавиться вообще от всего), но опять всё упирается в вопрос о целесообразности написания C++ компилятора для такой целевой архитектуры. В большинстве случаев, на таких микроконтроллерах решаются задачи, для которых чистого C хватает более чем.
когда это продукт, то лучше использовать официально бесплатные инструменты.
Скорее не бесплатные, а лицензионные. Если у фирмы есть лицензия на IAR, то почему бы им не воспользоваться? А если нет, то может стоит поставить вопрос о приобретении лицензии? Можно, конечно, и без колёс толкать телегу, говоря, что так бесплатно, но с колёсами удобнее.
я не специалист в теории внутренней работы компиляторов.
Я тоже не специалист по компиляторам, но за любые приятности языка приходится платить размером кода и занимаемой памяти.
компилятор C++11 для устройства с тридцатью двумя байтами RAM и килобайтом FLASH
Если ограничения настолько суровые, то проблема не в том чтобы написать компилятор, а в том, чтобы написать программу, которая запустится. Компилятор будет стабильно выдавать программу с потреблением RAM > 32 байт и/или общим размером > килобайта.
Можно, конечно, заставить компилятор оптимизировать данный код по размеру, но вряд ли экономически оправдано писать C++ компилятор для устройств с 32 байтами RAM и килобайтом FLASH, ибо под такие устройства скорее уж на их ассемблере писать надо.
Про конкретные фреймворки интересно было прочитать в плане того какие там встречались проблемы и как их решали. Понятно, что это не относится к самому DI, но когда из книги выкидывают главы, напрягает.
Лучше читать на английском, ибо при переводе пропало несколько глав (например, у нас используется MEF и Unity, а их выкинули из русской версии). Да и перевод, хоть и удобоварим, но всё равно местами отвлекает.
В 70е годы на Балабановскую спичечную фабрику пришло письмо. Написал один мужик примерно следующее. «Я 11 лет считаю спички у вас в коробках — и то 59, то 60, а иногда и 58. Вы там е*анулись что ли все?»
Если про конкретный код, то он не представляет никаких проблем и любой компилятор спокойно выдаст оптимальный по размеру/скорости (в зависимости от флагов) код. И вообще любой код, который не далеко ушёл от чистого C, тоже не будет представлять проблем.
Если же про 32 байта RAM, то проблемы будут начиная с виртуальных методов (32 байта RAM очень быстро будут съедены таблицами виртуальных методов и лишними указателями) и прочего. Теоретически, вполне можно и это всё тоже оптимизировать (на таком микроконтроллере никто же не будет ничего подгружать динамически, поэтому вполне можно на этапе компиляции избавиться вообще от всего), но опять всё упирается в вопрос о целесообразности написания C++ компилятора для такой целевой архитектуры. В большинстве случаев, на таких микроконтроллерах решаются задачи, для которых чистого C хватает более чем.
Скорее не бесплатные, а лицензионные. Если у фирмы есть лицензия на IAR, то почему бы им не воспользоваться? А если нет, то может стоит поставить вопрос о приобретении лицензии? Можно, конечно, и без колёс толкать телегу, говоря, что так бесплатно, но с колёсами удобнее.
Я тоже не специалист по компиляторам, но за любые приятности языка приходится платить размером кода и занимаемой памяти.
Если ограничения настолько суровые, то проблема не в том чтобы написать компилятор, а в том, чтобы написать программу, которая запустится. Компилятор будет стабильно выдавать программу с потреблением RAM > 32 байт и/или общим размером > килобайта.
Можно, конечно, заставить компилятор оптимизировать данный код по размеру, но вряд ли экономически оправдано писать C++ компилятор для устройств с 32 байтами RAM и килобайтом FLASH, ибо под такие устройства скорее уж на их ассемблере писать надо.
Свиная котлета с начинкой из камамбера
Апельсиновое конфи
Брусничный соус
Подойдёт к стауту или портеру
Обычная разводка при помощи TopoR
Так есть же возможность через ruleset (или как он там называется)