Динамические переменные и массивы, Можно ли задать динамические массивы ? Опции

[Navovvol]

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

[demiurg_spb]

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

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

[Tarbal]

+ ещё есть такая возможность.

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

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

[demiurg_spb]

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

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

[Tarbal]

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

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

В совсем маленьких контроллерах и эти 4 байта на вес золото. А вы говорите malloc...

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

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

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

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

[demiurg_spb]

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

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

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

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

[Tarbal]

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

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

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

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

[demiurg_spb]

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

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

[Tarbal]

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

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

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

Причина редактирования: бездумное цитирование