Буду краток. Работают ли операторы "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.

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

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

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

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

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

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

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



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





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

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

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

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

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

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

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

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

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

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

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

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

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

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

На самом деле в эмбеддед всякие alloc штука хорошая, только вот стандартный менджер не шибко хорош, можно попасть на фрагментацию памяти, в пределе до идиотизма , когда свободна половина, а два байта не выделить . Тут лучше упрощенный менеджер с аллокациями пулов фиксированного (обычно кратного степени двойки) кусками. И чего это стеку вдруг беспредельничать ? Не надо пользовать рекурсию и его максимальный требуемый размер будет очень даже предсказуем.

А без рекурсии не получится. Ведь по условию задачи приходят новые сообщения и их надо куда-то принимать. Или вы видите другой сценарий?

Причем тут рекурсия вообще ? Данные принимаются в буфер, не важно один ли он, или два с очередью, в куче ли, на стеке ли - главное что они предсказумы. Непредсказуемая может быть рекурсия, но никак не прием информации

Я в подобных случаях поступал следующим образом:
создавал на оставшуюся свободной области памяти массив элементов. Размер элемента равен максимально возможному сообщению. Далее создавал функции для запроса элемента и возвращения элемента. Все элементы имели заголовок для соединения их в односвязные списки. Пул свободных элементов тоже был оформлен как список.
Забавная история спучилась с Микрочипом. Компилятор молча укоротил мой массив до конца страницы адреса. В Микрочипе страничная адресация это бич. За что я люблю aтмелевские процессоры -- они свободны от этого нонсенса.





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

Да не буду я ничего приводить, берете какие-то левые ситуации. Если нет места в буфере - пусть идут все лесом, берем другой контроллер. Еще раз - я спросил причем тут рекрсия, а вы пишите про привести пример. Может тогда приведете пример, как рекурсия поможет сначала ?

Во-первых пример не мой, а во-вторых я не знаю как рекурсия поможет. Знаю, что она убьёт содержимое памяти.
Давайте подождем автора примера. Я надеюсь у него есть сценарий.

Вопрос к вам. Я правильно вас понял? Для того, чтобы с созданием массивов в стэке не было проблем надо быть аккуратным с их использованием? Или для этого надо предпринять какие-то меры?




Посреди улицы разговаривают два одессита. К ним подходит третий. Долго молча слушает, затем резко разворачивается и, уходя, говорит: – Ой! Та не морочьте мне голову…

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

т.е. в принципе выше правильно прозвучала мысль - что можно и так и так использовать память. и так и так можно убить(либо не убить) всю работоспособность. т.е. в конечном итоге это консерватория - кто как просче и надёжней привык(умеет, знает как) делать.

"А без рекурсии не получится. Ведь по условию задачи"
Только я противоречие в ваших же словах вижу ? Вы не знаете, как она поможет, но уверены, что без нее не получится ?

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

Конечно создаётся, вы ведь так и не смогли сказать, что использование кучи, в приведённом мной примере, на этапе компиляции вам никак не поможет. А про рекурсию - это уже ваши домыслы. Я не предлагал ничего подобного никогда. Извините, но с вами очень трудно разговаривать. Я об одном спрашиваю а вы всё продолжаете быть на своей волне. Разрешите откланяться!

+100500 Слишком много додумываний и предположений...

О! Вы появились. Прокоментируйте, пожалуйста мой ответ #17 на ваш #16.



Сливаете?


Виноват, домыслил.
Тогда к вам вопрос.

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

Вобщем malloc использовать стал в микроконтролерах когда у них стало 512 метров ддр внешней. И честно говоря все равно неспокойно. Фрагментация вещь непредсказуемая, но при таких объемах можно считать вероятность отказа незначительной.Это не значит, что нужно отказывать от дин. выделения в мелких, но не родным аллокатором. Говорить о куче в контексте когда все озу килобайт — смешно имхо. Да и не надо было, это же не вебсервер непредсказуемый, да и цена отказа моих программ высоковата, поэтому только стек + статические выделенные буфер ы. Да, никаких вызовов stdlib из прерываний.


Мне кажется Вы слово рекурсия неверно понимаете. А описанную задачу решают с помощью двойной буферизации, пока один буфер принимает — он только принимает.Как заполнен — идет его обработка, а на прием подставляется второй.Совершенно общая практика, начиная от контроллера SPI на верилоге и заканчивая V4L video for Linux.

То есть для использования двух буферов на стеке надо иметь два треда, каждый из которых берет из стека буфер? Надо синхронизировать не только рессурс выхода, но и размер буфера, чтобы не убить стэком переменные.

Не слишком ли сложно?

Может проще malloc() или еще проще тот метод, который я описал.

Или как-то иначе можно?

Не слишком . Это гораздо безопаснее всего остального. И мы коня в вакууме обсуждаем, все это без операционки можно.Знаете присказку, глупцы сложность игнорируют, умные с ней мирятся, а гении — устраняют.Или как то так. Хотите надежно — должно быть просто.

пс, успокойтесь про стек, есть просто заранее выделенные буфера.Это не маллок, это просто и тупо char buff (size)

Tarbal, смотрите мой комментарий к Вашему предыдущему посту.

Это вы коня в вакууме обсуждаете.
Какой-то театр абсурда. Причем здесь статические буферы? Я обсуждаю только одну тему:
СОЗДАНИЕ ДИНАМИЧЕСКИХ МАССИВОВ ПЕРЕМЕННОЙ ДЛИНЫ НА СТЕКЕ ОПАСНАЯ ПРАКТИКА.


Если вы полагаете, что вы можете меня чему-то научить, то могу вас заверить это очень маловероятно.

Динамические на стеке ? Это как ? Учить Вас и не думаю, это, судя по всему, бесполезно (конечно же потому, что куда уж мне до таких познаний, а не потому, что можно было подумать)

Variable length array служит для другого, а именно - для создания массива с классом памяти auto, размер которого зависит от значений, полученных во время выполнения. Это совсем не тот динамический массив, который подразумевается в этой дискуссии. Это просто красивое замещение alloca().

Что до фрагментации в куче - переход к дескрипторам со встроенным счетчиком ссылок приводит к такому набору

После чего оптимизация дыр в куче - делается на этапе освобождения памяти.
Очевидно, что дополнительные накладные расходы не очень тяжелые, поскольку для доступа нужно один раз выделить auto указатель и выполнить ref()
Auto дескриптор с cleanup атрибутом работает прекрасным уборщиком мусора, а статические дескрипторы не нуждаются в unref()
Такие вот мысли...

ps исправил неточности. Если чего пропустил, делайте замечания.

Один вопрос - нафига все это ? С такой системой не пройти ни одну сертификацию, она непредсказуема. Для развития мозгов - отлично, не спорю. Мое имхо - памяти должно быть с запасом, а ее расход - предсказуем. Что реализуется статичными массивами и все тут.
ЗЫ из вашего кода вообще ничего неясно. Если реализован сборщик мусора, то и вся Сшная процедура работа с указателями идет лесом, все надо делать либо на переопределенных операторах С++ либо их эмуляцией. Что означает крайне тяжелые расходы по обращению к ним. Легковестность сборщика мусора не в счет - она мало где играет роль.

1. Я тоже в том мнении, что куча нужна крайне редко. Но критерии детерминированности расхода памяти сводятся к решению проблемы утечки памяти из-за

• фрагментации
• плохого поведения алгоритма
• ошибок использования кучи

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

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

Куда ушли те времена, когда требовалось мастерство? Немерянной вычислительной силой можно все что угодно проломить. Зачем нам C++? Давайте сразу Java использовать.

Кстати, понравившийся многим манагер кучи от Zltigo вроде в выделяемом блоке содержал указатель на объект, получивший память? Я ничего не путаю? Ибо, если так, дефрагментация при соблюдении условия - не устраивать эстафету с передачей адреса от указателя к указателю (что действительно редкость) - простое дело. А я тут всякоразно выдумываю...

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

Да. Это у меня почему то навязчиво лезет слово "динамический" применительно к массиву переменной длины.
Ещё раз за это прошу прощения.