[AHTOXA 14]

В общем new (std::nothrow) объем кода не уменьшает...(((

Вообще-то должен. Посмотрите вот эту тему,

потом дополнительно убедитесь, что:

• вы не забыли ключики -fno-exceptions и -fno-rtti для компилятора;
• все варианты new() переопределены с nothrow;
• к проекту подключен вот этот файл;
• вы не забыли написать свой вариант _sbrk() (штатный вариант от codesourcery может тянуть за собой исключения. kgp в этом смысле лучше);

Я уверен, что после выполнения всех этих условий ваши волосы станут мягкими и шелковистыми:)

 

 

[haker_fox 60]

Вообще-то должен. Посмотрите вот эту тему,

потом дополнительно убедитесь, что:

• вы не забыли ключики -fno-exceptions и -fno-rtti для компилятора;
• все варианты new() переопределены с nothrow;
• к проекту подключен вот этот файл;
• вы не забыли написать свой вариант _sbrk() (штатный вариант от codesourcery может тянуть за собой исключения. kgp в этом смысле лучше);

Я уверен, что после выполнения всех этих условий ваши волосы станут мягкими и шелковистыми:)

Все, что Вы перечислили у меня есть (от части из scmRTOS). Но шампунь не помогает) Волосы мягкими и шелковистыми не стали) В мап-файле видно, что тянутся исключения

/arm-none-eabi/lib\libstdc++.a(eh_exception.o)

Во вложениее полный map-файл...

2xTermARM7.7z

[AHTOXA 14]

А если взять kgp?

Или попробуйте скомпилировать приложенный пример. У меня он компилируется в следующие объёмы:

codesourcery : 32K

kgp : 18K.

stm32_minimal_with_printf_and_new.zip

[haker_fox 60]

А если взять kgp?

Или попробуйте скомпилировать приложенный пример. У меня он компилируется в следующие объёмы:

codesourcery : 32K

kgp : 18K.

stm32_minimal_with_printf_and_new.zip

Ваш компилируется) Мой не компилируется сборкой от Клена( Просто выдает это

--- compiling .\src/isrHandlers.cpp...
make: *** [obj/isrHandlers.o] Error 1

Кстати, а за счет чего kgp так рулит по объему (почти в два раза)?

[alx2 0]

Во вложениее полный map-файл...

Насколько я вижу из вашего map-файла, eh_exception.o тянет за собой ваш ./obj/main.o из-за использования std::ios_base::Init::Init().

Каким образом это связано с операторами new и delete, я не знаю...

[haker_fox 60]

Насколько я вижу из вашего map-файла, eh_exception.o тянет за собой ваш ./obj/main.o из-за использования std::ios_base::Init::Init().

Каким образом это связано с операторами new и delete, я не знаю...

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

 

Правда без

include <iostream>

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

[AHTOXA 14]

Ваш компилируется)

И какой объём у вас получился?

Кстати, а за счет чего kgp так рулит по объему (почти в два раза)?

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

 

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

 

Если поключить файл new.cpp из проекта, выложенного выше уважаемым пользователем AHTOXA, то размер уменьшает до 50 кБ :rolleyes:

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

• все варианты new() переопределены с nothrow;

:)

[haker_fox 60]

И какой объём у вас получился?

32500 (cs)

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

 

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

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

[DmitryM 0]

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

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

[haker_fox 60]

Правда без

include <iostream>

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

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

 

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

 

[beaRTS 0]

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

[kolobok0 0]

...кто какие паттерны использует, какие полезны в embedded?

 

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

 

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

 

по поводу, что читать.

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

 

и я бы порекомендовал

Джэф Элджер "С++"

она правда не по ОО а больше по технике и языку. Но взгляд расширяется на возможности языка. Ну и осознание того, что есть ышо неизведанное :)

[beaRTS 0]

И ответьте мне - разве существуют в жизни одинаковые задачи? :) надеюсь смысл понятен?

Задач одинаковых не существует. Смысл понятен.

Вот только, как по мне, паттерны = идиомы = методологии удобны при создании архитектурных частей системы. Тот же pimpl хорош, чтобы разделить абстрактный интерфейс, например, SPI от архитектурной реализации в используемом процессоре (регистры процессора). Потом просто достаточно менять реализацию под выбранный процессор - удобно, геммора меньше (ведь все мы ленивы, и делать одно и тоже сызнова для каждой новой задачи - не айс).

Делюсь найденными ссылками.

youdevelop : даны тезисы когда следует применять

Design Patterns for Real-time and Embedded System Design

 

 

по поводу, что читать.

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

[kolobok0 0]

...паттерны = идиомы = методологии удобны при создании архитектурных частей системы....достаточно менять реализацию под выбранный процессор...

 

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

 

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

Изменено 8 октября, 2012 пользователем kolobok0

[beaRTS 0]

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

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