H>>Вот вот. Так всегда кажется — сейчас под Win32 отладим, а потом пересоберем "хоть под AVR". Как низкоквалифицированый кодер скажу что так не работает никогда и ни у кого. _Все_ вещи связанные с кодированием и декодированием видео перенесенные на embedded платформы (т.е. там где производительность критична) были написаны на С и оптимизированы вначале именно на С под конкретную платформу. Перенос этого на другую платформу как правило требует архитектурных изменений кода.
П>Я не говорю "спроектировать и написать чисто на Win32, а потом перекомпилять". Я утверждаю, что можно изначально спроектировать систему так, что отладка "бизнес-логики" пройдет на Win32, а под железом останутся вопросы оптимизации и отладки 10% аппаратно-зависимого кода. Приведу пример. Однажды разрабатывал я местячковый такой фреймворк для распределенных вычислений. Среди железных платформ были AVR, AT91SAM7 и т.п. И "изюминкой" проекта был хитрый самосинхронизирующийся протокол обмена данными между контроллерами. На самом начальном этапе проектирования было принято решение сделать самый нижний уровень переключаемым: заменяем BusDriver<AVR::UART1> на BusDriver<Simulator::UART<GlobalUART_A>> и собираем Win32-версию а-ля по потоку на симулируемое ядро. Вот только малая доля багов, обнаруженных в реализации протокола:
П>Забытый вызов функции синхронизации времени
П>Ошибки в последовательности вызова обработчиков транзакций
П>Забытый case в обработчике прерываний от UART

П>Писалось бы все на чистом С и сразу под AVR, каждое из перечисленного приводило бы к ситуации "упс, чаво-то плата зависла, понять бы, какой из контроллеров виноват". В Студии же все баги находились и исправлялись на лету, ибо отладчик с визуализацией типов и всякие перки а-ля отображение timestamp-а в debug name потока упрощают отладку в разы.
П>Подобную абстракцию можно было бы реализовать и на C, но это были бы тонны копипасты и find-and-replace... В "плюсах" же все решается заменой аргумента шаблона...
Да, в общем-то на С делается две библиотеки — одна AVR_UART, другая Simulator_UART. все отлаживается, переносится и т.д. Но не в том суть. Наверное надо сказать, что embedded конечно бывает разное. Например если надо написать хм... браузер или там RSS ридер под S60, то очевидно надо использовать всю мощщььь ООП . Просто, ну реально сталкивался (не раз) с такими ситуациями когда банально лишняя операция доступа к памяти приводила к тому что производительности не хватало. Или (в случае с параметризируемыми типами который Вы привели) лишние 10 байт уже не влазили во внутреннюю память.

H>>Повторюсь, так делают практически все (я работал с кодом таких "брендов" как Analog Devices, Intel, TI, KORG, etc.). Видимо у них ни у кого не было времени почитать александреску (ничего личного)
П>10 лет назад не было GCC 4.x и существующие оптимизаторы действительно не позволяли делать хорошее абстрагирование, не принося в жертву производительность. "Бренды" зачастую очень консервативны, так что это не показатель. Многие "бренды" до сих пор используют ПО управления конвейерами, написанное под DOS. Это не значит, что писать современный код под DOS удобнее, чем под современые ОС.
Ну про брендов — это я в ответ на Александреску. Сейчас как мне кажется вообще нет проблемы с фронт-эндом — GCC/LLVM можно приспособить для любой платформы, а с кодогенератором проблема будет что с С что с С++ если платформа более менее сложная (например не видел ни разу такого компилятора ни для одной из VLIW платформ, чтобы не приходилось руками код на асме писать)..

В общем embedded она разное, ага.