[juvf 17]

Использую компилятор icc430 для msp430. пробую стандартные шаблоны. если объявлении

list<int> myIntList;

myIntList.push_back(43); //этот вызов работает

list<myClass> myClassList;

myClass obj;

list.push_back(obj); //в этом месте программа сваливается.

вообще при попытке вставить в контейнер list или map программа сваливается. Кто нибудь использовал стандартные шаблоны в иаре? Они в иаре рабочие? Может нужно какую нибудь опцию компилятору передать, чтоб list заработал?

[sergeeff 1]

А должно быть:

 

list<int> myIntList;
myIntList.push_back(43); //этот вызов работает
list<myClass> myClassList;
myClass obj;
myClassList.push_back(obj);

[juvf 17]

А должно быть:

 

list<int> myIntList;
myIntList.push_back(43); //этот вызов работает
list<myClass> myClassList;
myClass obj;
myClassList.push_back(obj);

опечатался. тот бы код компилятор не пропустил. вообщем на myClassList.push_back(obj); программа сваливается.

[dxp 64]

опечатался. тот бы код компилятор не пропустил. вообщем на myClassList.push_back(obj); программа сваливается.

STL требует работы с памятью, каждый контейнер имеет стандартный аллокатор, который обращается к менеджеру памяти с целью выделения оной под размещение объектов. Поэтому нужно проследить, что менеджер памяти имеет достаточно ресурсов для своей работы - размещена "куча" (Heap) достаточного размера. По умолчанию там у нее размер какой-то смешной - что-то порядка 16 байт. Этого хватает для одного обращения, а на втором уже облом.

 

Вообще, стандартный менеджер памяти не очень хорошо подходит под embedded - слишком он универсальный, требовательный к ресурсам (память и быстродействие) и подвержен фрагментации. Поэтому в embedded часто вместо стандартного используют более специализированные под конкретные задачи, не редко самописные. В случае с STL ситуация усугубляется еще тем, что при использовании нестандартного менеджера памяти придется писать и свои аллокаторы для контейнеров, а это требует довольно глубоких познаний внутренностей как самой STL, так и всего этого шаблонного механизма С++. Это не так просто.

 

В общем, я бы советовал подумать два раза, прежде чем браться за STL на MSP430 - немного не тот процессор, чтобы с ходу эффективно это на нем использовать. Не лишне будет рассмотреть альтернативные варианты реализации желаемой функциональности.

[juvf 17]

ну примерно так оно и есть. Проследил пошагово где именно в list сваливается: на алокаторе. В чем-то я с вами согласен. Наверно придется альтернативу искать. Но

Вообще, стандартный менеджер памяти не очень хорошо подходит под embedded - слишком он универсальный

С этим я тоже согласен, но почему стал пользовать stl - потому что коль иаровский компилятор (icc430) заточен именно под msp430, и для mps430 написан stl, и IAR декларирует нормальную работу stl - то должен быть не стандартный менеджер памяти, а менеджер памяти именно для embedded msp430. Вот в lib-avr четко прописали - с++ есть, но ограниченный: нет new, delete, и нет stl и шаблонов (по мойму этого нет тоже из-за сложностей с кучей). А тут всё есть, но не работает. ((

[dxp 64]

почему стал пользовать stl - потому что коль иаровский компилятор (icc430) заточен именно под msp430, и для mps430 написан stl, и IAR декларирует нормальную работу stl - то должен быть не стандартный менеджер памяти, а менеджер памяти именно для embedded msp430. Вот в lib-avr четко прописали - с++ есть, но ограниченный: нет new, delete, и нет stl и шаблонов (по мойму этого нет тоже из-за сложностей с кучей).

Менеджер памяти не может быть как-то заточен под MSP430. Он может просто реализовывать разные стратегии, из которых одни лучше подходят для конкретной задачи, другие - хуже. С пакетом поставляется универсальный, недостатки которого перечислены выше.

 

А тут всё есть, но не работает. ((

Увеличьте Heap (до несколькоих сотен байт хотя бы), и ваш пример заработает.