Embedded C++, Кто какие библиотеки использует? Опции

[segment]

Я не начинаю очередной холивар по поводу того что C++ не нужен для микроконтроллеров и прочее. Поэтому те, кто хочет поспорить - приводите убедительные факты куда угодно, но не в эту тему.

Само собой использование STL в программе под микроконтроллер сомнительно, так как, к примеру, работа с STL в Keil uVision 4 (видимо их порт STL) обходится в минимум 40 Кбайт (собрал пример из Keil examples). Поэтому выходом из этой ситуации вижу использование либо специальных готовых light библиотек либо написание базовых шаблонов/классов самому. Но так уже стадия "начинающий и все хочу попробовать" прошла уже давно, поэтому писать самому не сильно тянет.
Кто какие C++ библиотеки использует для работы с периферией и данными?

[haker_fox]

Да, Си++ иногда тянет за собой кучу ненужного и тяжелого (полагаю, что и Си иногда тоже). На AVR я с этим не сталкивался, но столкнулся на ARM7TDMI, когда захотел использовать динамическую память (оператор new). Как только использовал, так код с 40 кБ вырос до 300 кБ. Пока чихаю на это, т.к. идет отладка. Но потом хочу прикрутить "легкую" реализацию менеджера памяти, любезно представленного уважаемым zltigo, и не менее любезно адаптированным к Си++ уважаемым Сергеем Борщем.
От исключений пока отказался, там что-то чудесное и невероятное творится как с размером, так и компиляцией. Но мне оно сейчас не особо нужно, а вот без динамического выделения памяти очень плохо.

Как-то так.

Ну в общем подходишь к этому вопросу с необходимой долей разума. Где готовое используешь, где адаптируешь, где свое накропаешь)

[alx2]

Да, Си++ иногда тянет за собой кучу ненужного и тяжелого

А что именно? Мне кроме исключений (которые можно отключить при компиляции) ничего в голову не приходит...

На AVR я с этим не сталкивался, но столкнулся на ARM7TDMI, когда захотел использовать динамическую память (оператор new). Как только использовал, так код с 40 кБ вырос до 300 кБ.
Пока чихаю на это, т.к. идет отладка. Но потом хочу прикрутить "легкую" реализацию менеджера памяти, любезно представленного уважаемым zltigo, и не менее любезно адаптированным к Си++ уважаемым Сергеем Борщем.

Сейчас провел "экспресс-тест". Весь код программы, использующей new и delete, составил меньше 9 килобайт (arm7tdmi). Почему у Вас new/delete потянули дополнительные 260 килобайт, ума не приложу. Тем более, что Вы не используете исключения... В любом случае, к языку C++ как таковому это не имеет отношения. Напротив, наличие в языке этих операторов (и, главное, возможность их перегружать по своему усмотрению) дает программисту возможность более тонко контролировать работу с памятью. В тривиальном случае new/delete могут работать через malloc/free и, таким образом, ничем не будут отличаться от аналогичного кода на языке C. Ничего "ненужного" эти операторы сами по себе не "тянут".

[haker_fox]

Почему у Вас new/delete потянули дополнительные 260 килобайт, ума не приложу.

А вот и я не знаю... но стоит убрать эти операторы, как код становится 40 кБ...

С другой стороны, не зря же свои менеджеры памяти "выдумывают", значит проблема есть...

З.Ы. Компилятор у меня Code Sourcery...

[alx2]

А вот и я не знаю... но стоит убрать эти операторы, как код становится 40 кБ...

Но Вы-то, в отличие от нас, узнать это можете - достаточно заглянуть в map-файл...
Вы, надеюсь, использовали nothrow-версию оператора new?
А вот с такими реализациями:

Код

void * operator new(size_t n) throw() { return malloc(n); }
void operator delete(void *p) { free(p); }

тоже тянет 260 кбайт?

С другой стороны, не зря же свои менеджеры памяти "выдумывают", значит проблема есть...

К языку программирования это не имеет никакого отношения. Язык C++ позволяет использовать любой менеджер памяти (включая использование нескольких менеджеров одновременно - для разных объектов разных). Свой менеджер памяти может потребоваться писать по тысяче разных причин - это зависит от решаемой задачи. И необходимость писать свой менеджер не означает, что все прочие существующие менеджеры плохи. Это всего лишь означает, что они не подходят для данной конкретной задачи. При этом для другой задачи какой-то из них может подойти гораздо лучше, чем "выдуманный" Вами. Но это совсем другая тема - не о языках программирования...