Буду краток. Работают ли операторы "new" и "delete" ? Есть ли их аналоги ? Проект делается на Си.

Нет в си нет "new" и "delete", зато есть malloc и free.
+ ещё есть такая возможность.

The operators new and delete are not implemented, attempting to use them will cause the linker to complain about undefined external references. - это для GCC, а точнее winavr-20100110. Смотрите описание на используемый вами компилятор.
И если не ошибаюсь, операторов new и delete нет в Си, это С++. Используйте malloc(), realloc(), calloc(), free().

Спасибо. Если задуманное получиться, покажу, что вышло.

Для маленьких микропроцессоров не лучший способ создавать большие массивы в стеке.
Мне и для больших это не нравится. Лучше malloc() in heep.

Сообщение отредактировал Tarbal - Sep 11 2013, 17:04

Ничем не лучше.
Если компилятор умеет хорошо это делать, почему бы и нет?
Например iar-avr это делает отлично, а avr-gcc плохо.
Создание динамического массива любого размера фактически не несёт никаких накладных расходов (кроме пары коррекций вершины стека, что в iar выливается в 2 асм-инструкции или в ноль инструкций, если и так в процедуре выделялось место для стекового фрейма).
В совсем маленьких контроллерах и эти 4 байта на вес золото. А вы говорите malloc...

Создание - да, а разрушение?
Не говоря уже о сборке мусора.

Я говорил о создании массива переменной длины на стеке (слово динамический я в том контексте применил не к месту).
О какой сборке мусора речь? Всё само-собой получится при раскрутке стека обратно.

Значит, мы не об одном и том же говорим.
Локальный массив, живущий во время исполнения функции и динамический объект, живущий вплоть до его целенаправленного уничтожения, это все-таки разные вещи.

То есть, создавать так можно, на время перемещая SP в специальную огороженную область, а вот как обратно освобождать из-под произвольного объекта, да ещё в произвольный момент, что-то не представляю.

Да. Я говорю за массивы переменной длины, и совсем не касаюсь кучи и её менеджера.
Тут нет никакого произвольного времени, все не статические локальные переменные, не помещающиеся в регистрах,
живут в стековом фрейме функции, жизнь которого длиться до выхода из функции.
Соответственно на входе в функцию известен размер требуемого фрейма на стеке, на выходе из функции тоже.
Никаких затруднений нет.

Засада в том, что нет никаких способов контроля переполнения стека на момент компиляции и когда в rutime стек переполнится на крутом процессоре вы получите ексепшн, а на маленьком AVR трудноуловимые и плоховоспроизводимые странности поведения. Без никаких намеков на то, что в реальности происходит.



В совсем маленьких нет необходимости в динамической алокации массивов
Я всегда обходился.





Проще не пользоваться динамически создаваемыми массивами

Сообщение отредактировал Tarbal - Sep 12 2013, 12:40

Никакой разницы нет. Вот на куче выделили в очередной раз память - с контролем и всеми делами. А в это же время стек взял и наехал на кучу.
Повторюсь, нет никаких преимуществ у кучи перед стеком.
Тут всё просто, памяти либо хватает либо нет. Алгоритм оптимальный или нет. И в конечном итоге всё сводится к тому, что работает или нет.
А если работает и выполняет требования ТЗ - всё, оплата в кармане, ну или на карточке)))

я тоже, но случаи бывают разные.

Неверно. Стек сам по себе не наедет. Значит кто-то стеком неправильно пользуется. Алокация массивов на стеке это хороший способ наехать стеком. Если не делать таких вещей, то и проблем не будет. Использование кучи гарантирует от таких сюрпризов. Если нет фокусов с использованием стека.

Я сделал немало устройств и никогда не использовал динамическую алокацию. Значит можно обойтись.

Спор бесполезен.
Вы не понимаете моей основной мысли, что неважно кто наедет (стек или куча), важно то, что использовании кучи более ресурсоёмко чем стека.
А использование динамических массивов иногда очень красиво решает проблему нехватки памяти.
Вот пример (только что выдумал):
Алгоритм 1 (требует более половины ОЗУ для своего выполнения)
Алгоритм 2 (требует более половины ОЗУ для своего выполнения)
...
Алгоритм N (требует более половины ОЗУ для своего выполнения)

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

Не соглашусь с вами. Попытка наезда кучей вызовет ошибку компиляции и никогда не будет пропущена. С наездом стэка такое невозможно, а значит в реальности только стек и будет наезжать.

По поводу алгоритмов. Алгоритмы надо улучшать. В ембеддед программировании требования покруче чем при написании апликаций на PC

Сообщение отредактировал IgorKossak - Sep 13 2013, 14:54