Похоже это дело тянул <iostream>, который у меня был подключен. Я его исключил, и теперь код уменьшился в два раза ( 150 кБ). Если поключить файл new.cpp из проекта, выложенного выше уважаемым пользователем AHTOXA, то размер уменьшает до 50 кБ

Правда без я лишился строк Си++, которые очень удобны в работе...(

И какой объём у вас получился?
Видимо за счёт того, что klen специально боролся с исключениями. Или же наоборот, cs что-то понапихали своего.

ЗЫ. У кого есть YAGARTO, посмотрите пожалуйста, в какой объём компилится мой проект?


Ага! Значит всё же не был выполнен пункт

32500 (cs)
kgp вылетает с той же ошибкой(


Верно, слона-то я и не заметил

arm-none-eabi-gcc.EXE (GCC) 4.7.1

text data bss dec hex filename
27636 2244 600 30480 7710 ./exe/hello-stm32-printf-and-new.elf

Нет, не лишился. Но конструкторы строк за собой тянут около 100 кб дополнительно...

Кстати, классы, шаблоны, перегрузку и тп в embedded делаем, тут сомнений нет. А строки Си++ используем, или по старинке строки Си да что-нить printf-подобное? Я для себя сделал вывод, что последнее (т.е. printf) проще во встраиваемых приложениях, да и на большом брате тоже...

наткнулся на статью интересную Паттерны проектирования в Embedded . можете поделиться подобным образом (лучше, конечно, поподробнее, а если и с реальными примерами - будет здорово!) кто какие паттерны использует, какие полезны в embedded?

сейчас многие возбудятся, но патерны - это собственно для блондинок от программирования(чисто имхо). почему? очень просто. Читаете Буча(надеюсь авторитет одного из пап практического применения ООП и ООА не вызывает сомнений?) и видите, что помимо технических аспектов (полиморфизм, наследование и т.д.) всплывает очень мощная методология по переходу от задумки к коду. Именно методология. Именно она имеет ряд мощных плюсов. Ведь первым шагом идёт анализ задачи, нахождения сущностей, декомпозиция, нахождения связей и т.п.. Т.е. вы строите код от задачи(!). Т.е. если люди из предметной области говорят что машина крутит колёсами и перемещается из пункта А в пункт Б = то Вы используя именно эти сущности получаете статическое построение модели(!) которая не будет меняться во времени жизни всего проекта!!! Понимаете какая мощь? т.е. машина не превратиться в верблюда, а дорога в озеро! ни под каким соусом!!! Это только я озвучил первый плюс данной методы

ну а теперь возвращаемся к патернам. И ответьте мне - разве существуют в жизни одинаковые задачи? надеюсь смысл понятен? на мой взгляд инструмент патернов придумали для упрощения(читай снижения затрат) на обучение программистов(читай издержки производства) в эпоху 2000 годов, когда все домохозяйки шли в пилоты, тьху в программисты ну и к чему привело - понятно, шлёпнулось IT отрасль у них в 2001 (для тех кто не помнит).

по поводу, что читать.
не буду оригинален - Гради Буча естественно. Более того скажу - читать маловато будет. Именно стэп бай стэп конкретной вашей задачи сверяясь с книгой.

и я бы порекомендовал
Джэф Элджер "С++"
она правда не по ОО а больше по технике и языку. Но взгляд расширяется на возможности языка. Ну и осознание того, что есть ышо неизведанное

Задач одинаковых не существует. Смысл понятен.
Вот только, как по мне, паттерны = идиомы = методологии удобны при создании архитектурных частей системы. Тот же pimpl хорош, чтобы разделить абстрактный интерфейс, например, SPI от архитектурной реализации в используемом процессоре (регистры процессора). Потом просто достаточно менять реализацию под выбранный процессор - удобно, геммора меньше (ведь все мы ленивы, и делать одно и тоже сызнова для каждой новой задачи - не айс).
Делюсь найденными ссылками.
youdevelop : даны тезисы когда следует применять
Design Patterns for Real-time and Embedded System Design



за авторов спасибо! Закачаю, гляну

кто же говорит, что юзать повторно - есть зло? юзайте на здоровье. я не об этом говорил выше.

я о том, что подгонять задачу под "удобное" и "готовое" решение - есть зло, которое даст о себе знать гораздо позже и подлее чем можно себе представить и не важно на каком этапе оно уже готово и решено - на этапе проектирования и анализа, либо кодинга. кстати говоря, надо очень критично относиться к себе любимому, чтоб вовремя остановить бег мысли своей и сказать - опа, эта я уже пытаюсь подгонять под результат!!! т.е. решать задачу надо начинать с Анализа по любасику. И если на стадии принятия решения Вы не видите противоречий(любых, дажэ самых мало-мальских) в использовании ранее написанного(продуманного) багажа - кто-же мешает то?

ну да да. все логично говорите. согласен

C++ замечательный язык. Только надо уметь им пользоваться. Если использовать грамотно наследование и шаблоны (template), то получается восхитительный по объему и скорости код.
На обычном C такой код очень непросто написать.