Хахаха у zombi бомбануло прям так не слабо по ходу))))))))))
Не знаю, вроде zltigo дельные вещи говорил...

помог. вывод такой. взять камень с бОльшим RAM. дешевле чем внешнюю память ставить.

В однозадачном режиме использовать кучу безопасно. Выделил фрагмент, попользовался, освободил. Сложнее, когда задач несколько, и каждая может попросить памяти. Как определить худший случай, когда требуется максимальный объем?

Т.е. совет использовать менеджер памяти подтолкнул Вас к решению "взять камень с бОльшим RAM"?
Феерично!
Или это сарказм такой?

Почитайте сообщение №51.

Не имею возражений к Вашему сообщению №51

И мне кажется что ТС сам же и ответил на свой вопрос написав:

Т.е. на этапе проектирования количество необходимой памяти не определено даже приблизительно.
О каких менеджерах вообще может идти речь?

Мы с zltigo привели реальные примеры, когда пересмотр архитектуры позволил "найти" нужное количество памяти.
Если ТС не способен ухитриться (или задача не позволяет), то для него путь - тупо увеличить объем ОЗУ.
Отрицать на вашем месте вообще подход с использованием менеджеров памяти - не профессионально.

тут нужно решать концептуально. есть 10 задач. либо загрузить их в RAM и проходить итерацией , либо брать по одной - загрузил-освободил - тогда можно и с malloc/free. но во втором случае возникает вопрос - где держать задачи.

хорошо. я написал код для PLC. В Ladder Diagram или мнемоник. где хранится пограмма которую PLC исполняет?

идея.положу во флеш..если останется место. он что то тоже стремительно убывает.

Сообщение отредактировал Jenya7 - Mar 13 2016, 13:35

Обвинять кого либо в том чего он не говорил - не порядочно.

Значит менеджеры памяти в некоторых задачах нужны.
Пригодность задачи для использования динамического выделения памяти определяет разработчик.
Если задача непригодна (пусть даже по причине отсутствия опыта у исполнителя) - наращиваем ОЗУ.
Все - конфликт исчерпан. Я прошу меня простить, если с кем-то поступил не порядочно.

...

Тема исчерпана - неплохо бы закрыть и последнее почистить.

Ну значит так и есть
Удалил, мне не сложно.
А насчёт "закрыть" это лучше к ТС писать


Может СИшникам и нужны, мне точно не нужны.
Для меня это просто часть алгоритма и как его обозвать не имеет значения.

Создать глобальное объединение (union) из массивов всех нужных типов, максимально необходимого размера, и пользоваться им по мере необходимости вместо кучи. Годится?
Хочу понять, как куча может помочь сэкономить память? Если требуется хранить глобальные переменные, но никуда не денешься, придется выделить для них память сразу и навсегда. Если локальные, так они где создаются - в стеке или в куче? Кто (что) решает?

P.S. Или приведением указателя к нужному типу пользоваться массивом целых и в хвост и гриву.

Никак. Может привести только к бОльшему расходу памяти.
Куча полезна только если нужно запускать различные задачи, заранее не известные (когда и какую), с заранее неизвестными требованиями к памяти. Но и то - нужна обработка случая нехватки памяти. Да и дефрагментация периодическая или после завершения каждой задачи. Это случай Linux-а и подобных ему систем.

Обычно для ембеддед достаточно:
union MemShare {
struct MemMode1 {
int member1, member2;
...
} memMode1;
struct MemMode2 {
int member1, member2;
...
} memMode2;
...
} memShare;
где Mode1, Mode2, ... - состояния работы устройства с неперекрывающимися структурами данных; которые в свою очередь могут быть union и делиться дальше.