Здравствуйте, hokkaido, Вы писали:

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... В "плюсах" же все решается заменой аргумента шаблона...

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