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

[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

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

[demiurg_spb]

Попытка наезда кучей вызовет ошибку компиляции и никогда не будет пропущена.

Как это? Приходят пакеты из одно порта и ретранслируются в другой (по разным протоколам).
И всё это гипотетически реализовано через кучу. Вдруг выходной канал отваливается, а на входе поток не прерываем (так случилось).
А вы продолжаете создавать на куче пакты, пока она не закончится.
Вопрос: как вам применение кучи поможет на этапе компиляции? (отвечайте пожалуйста конкретно и не юлите)

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

Только не надо меня кормить этими дежурными фразами, что не надо, а что надо...

[Tarbal]

Как это? Приходят пакеты из одно порта и ретранслируются в другой (по разным протоколам).
И всё это гипотетически реализовано через кучу. Вдруг выходной канал отваливается, а на входе поток не прерываем (так случилось).
А вы продолжаете создавать на куче пакты, пока она не закончится.
Вопрос: как вам применение кучи поможет на этапе компиляции? (отвечайте пожалуйста конкретно и не юлите)

Только не надо меня кормить этими дежурными фразами, что не надо, а что надо...

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

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

Скажите, у вас создалось впечатление, что я уклоняюсь от ответов на какие-то ваши вопросы? Укажите мне на эти вопросы и вы увидите, что ваше впечатление ошибочно. Я прадоставлю вам исчерпывающий ответ.