Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Динамические переменные и массивы
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
Navovvol
Буду краток. Работают ли операторы "new" и "delete" ? Есть ли их аналоги ? Проект делается на Си.
demiurg_spb
Цитата(Navovvol @ Sep 2 2013, 11:51) *
Буду краток. Работают ли операторы "new" и "delete" ? Есть ли их аналоги ? Проект делается на Си.

Нет в си нет "new" и "delete", зато есть malloc и free.
+ ещё есть такая возможность.
Bear_ku
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().
Navovvol
Спасибо. Если задуманное получиться, покажу, что вышло.
Tarbal
Цитата(demiurg_spb @ Sep 2 2013, 11:55) *
+ ещё есть такая возможность.


Для маленьких микропроцессоров не лучший способ создавать большие массивы в стеке.
Мне и для больших это не нравится. Лучше malloc() in heep.
demiurg_spb
Цитата(Tarbal @ Sep 11 2013, 21:04) *
Для маленьких микропроцессоров не лучший способ создавать большие массивы в стеке.
Мне и для больших это не нравится. Лучше malloc() in heep.
Ничем не лучше.
Если компилятор умеет хорошо это делать, почему бы и нет?
Например iar-avr это делает отлично, а avr-gcc плохо.
Создание динамического массива любого размера фактически не несёт никаких накладных расходов (кроме пары коррекций вершины стека, что в iar выливается в 2 асм-инструкции или в ноль инструкций, если и так в процедуре выделялось место для стекового фрейма).
В совсем маленьких контроллерах и эти 4 байта на вес золото. А вы говорите malloc...
MrYuran
Цитата(demiurg_spb @ Sep 12 2013, 09:42) *
Создание динамического массива любого размера фактически не несёт никаких накладных расходов (кроме пары коррекций вершины стека

Создание - да, а разрушение?
Не говоря уже о сборке мусора.
demiurg_spb
Цитата(MrYuran @ Sep 12 2013, 11:00) *
Создание - да, а разрушение?
Не говоря уже о сборке мусора.
Я говорил о создании массива переменной длины на стеке (слово динамический я в том контексте применил не к месту).
О какой сборке мусора речь? Всё само-собой получится при раскрутке стека обратно.
MrYuran
Цитата(demiurg_spb @ Sep 12 2013, 10:27) *
О какой сборке мусора речь? Всё само-собой получится при раскрутке стека обратно.

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

То есть, создавать так можно, на время перемещая SP в специальную огороженную область, а вот как обратно освобождать из-под произвольного объекта, да ещё в произвольный момент, что-то не представляю.
demiurg_spb
Цитата(MrYuran @ Sep 12 2013, 11:52) *
Значит, мы не об одном и том же говорим.
Да. Я говорю за массивы переменной длины, и совсем не касаюсь кучи и её менеджера.
Цитата
Локальный массив, живущий во время исполнения функции и динамический объект, живущий вплоть до его целенаправленного уничтожения, это все-таки разные вещи.
То есть, создавать так можно, на время перемещая SP в специальную огороженную область, а вот как обратно освобождать из-под произвольного объекта, да ещё в произвольный момент, что-то не представляю.
Тут нет никакого произвольного времени, все не статические локальные переменные, не помещающиеся в регистрах,
живут в стековом фрейме функции, жизнь которого длиться до выхода из функции.
Соответственно на входе в функцию известен размер требуемого фрейма на стеке, на выходе из функции тоже.
Никаких затруднений нет.
Tarbal
Цитата(demiurg_spb @ Sep 12 2013, 10:42) *
Ничем не лучше.
Если компилятор умеет хорошо это делать, почему бы и нет?
Например iar-avr это делает отлично, а avr-gcc плохо.
Создание динамического массива любого размера фактически не несёт никаких накладных расходов (кроме пары коррекций вершины стека, что в iar выливается в 2 асм-инструкции или в ноль инструкций, если и так в процедуре выделялось место для стекового фрейма).
В совсем маленьких контроллерах и эти 4 байта на вес золото. А вы говорите malloc...


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

Цитата(demiurg_spb @ Sep 12 2013, 10:42) *
В совсем маленьких контроллерах и эти 4 байта на вес золото. А вы говорите malloc...


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



Цитата(MrYuran @ Sep 12 2013, 11:00) *
Создание - да, а разрушение?
Не говоря уже о сборке мусора.


Проще не пользоваться динамически создаваемыми массивами sm.gif
demiurg_spb
Цитата(Tarbal @ Sep 12 2013, 16:43) *
Засада в том, что нет никаких способов контроля переполнения стека на момент компиляции и когда в rutime стек переполнится на крутом процессоре вы получите ексепшн, а на маленьком AVR трудноуловимые и плоховоспроизводимые странности поведения. Без никаких намеков на то, что в реальности происходит.
Никакой разницы нет. Вот на куче выделили в очередной раз память - с контролем и всеми делами. А в это же время стек взял и наехал на кучу.
Повторюсь, нет никаких преимуществ у кучи перед стеком.
Тут всё просто, памяти либо хватает либо нет. Алгоритм оптимальный или нет. И в конечном итоге всё сводится к тому, что работает или нет.
А если работает и выполняет требования ТЗ - всё, оплата в кармане, ну или на карточке)))

Цитата
В совсем маленьких нет необходимости в динамической алокации массивов sm.gif
я тоже, но случаи бывают разные.
Tarbal
Цитата(demiurg_spb @ Sep 12 2013, 16:56) *
Никакой разницы нет. Вот на куче выделили в очередной раз память - с контролем и всеми делами. А в это же время стек взял и наехал на кучу.
Повторюсь, нет никаких преимуществ у кучи перед стеком.
Тут всё просто, памяти либо хватает либо нет. Алгоритм оптимальный или нет. И в конечном итоге всё сводится к тому, что работает или нет.
А если работает и выполняет требования ТЗ - всё, оплата в кармане, ну или на карточке)))

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


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

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

И эти алгоритмы вызываются поочерёдно.
Очень красиво и просто решается с использованием стека.
Никаких лишних завязок на какой-то глобальный пул.
Никаких менеджеров памяти.
Ничего лишнего, только суть алгоритма. Не это-ли является нашей основной парадигмой?
Tarbal
Цитата(demiurg_spb @ Sep 13 2013, 10:38) *


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

По поводу алгоритмов. Алгоритмы надо улучшать. В ембеддед программировании требования покруче чем при написании апликаций на PC
demiurg_spb
Цитата(Tarbal @ Sep 13 2013, 16:29) *
Попытка наезда кучей вызовет ошибку компиляции и никогда не будет пропущена.

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

Цитата
По поводу алгоритмов. Алгоритмы надо улучшать. В ембеддед программировании требования покруче чем при написании апликаций на PC
Только не надо меня кормить этими дежурными фразами, что не надо, а что надо...
Tarbal
Цитата(demiurg_spb @ Sep 13 2013, 16:40) *
Как это? Приходят пакеты из одно порта и ретранслируются в другой (по разным протоколам).
И всё это гипотетически реализовано через кучу. Вдруг выходной канал отваливается, а на входе поток не прерываем (так случилось).
А вы продолжаете создавать на куче пакты, пока она не закончится.
Вопрос: как вам применение кучи поможет на этапе компиляции? (отвечайте пожалуйста конкретно и не юлите)

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


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

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

Скажите, у вас создалось впечатление, что я уклоняюсь от ответов на какие-то ваши вопросы? Укажите мне на эти вопросы и вы увидите, что ваше впечатление ошибочно. Я прадоставлю вам исчерпывающий ответ.
DASM
На самом деле в эмбеддед всякие alloc штука хорошая, только вот стандартный менджер не шибко хорош, можно попасть на фрагментацию памяти, в пределе до идиотизма , когда свободна половина, а два байта не выделить . Тут лучше упрощенный менеджер с аллокациями пулов фиксированного (обычно кратного степени двойки) кусками. И чего это стеку вдруг беспредельничать ? Не надо пользовать рекурсию и его максимальный требуемый размер будет очень даже предсказуем.
Tarbal
Цитата(DASM @ Sep 13 2013, 17:35) *
На самом деле в эмбеддед всякие alloc штука хорошая, только вот стандартный менджер не шибко хорош, можно попасть на фрагментацию памяти, в пределе до идиотизма , когда свободна половина, а два байта не выделить . Тут лучше упрощенный менеджер с аллокациями пулов фиксированного (обычно кратного степени двойки) кусками. И чего это стеку вдруг беспредельничать ? Не надо пользовать рекурсию и его максимальный требуемый размер будет очень даже предсказуем.


А без рекурсии не получится. Ведь по условию задачи приходят новые сообщения и их надо куда-то принимать. Или вы видите другой сценарий?
DASM
Причем тут рекурсия вообще ? Данные принимаются в буфер, не важно один ли он, или два с очередью, в куче ли, на стеке ли - главное что они предсказумы. Непредсказуемая может быть рекурсия, но никак не прием информации
Tarbal
Цитата(DASM @ Sep 13 2013, 17:35) *
На самом деле в эмбеддед всякие alloc штука хорошая, только вот стандартный менджер не шибко хорош, можно попасть на фрагментацию памяти, в пределе до идиотизма , когда свободна половина, а два байта не выделить . Тут лучше упрощенный менеджер с аллокациями пулов фиксированного (обычно кратного степени двойки) кусками. И чего это стеку вдруг беспредельничать ?


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


Цитата(DASM @ Sep 13 2013, 18:01) *
Причем тут рекурсия вообще ? Данные принимаются в буфер, не важно один ли он, или два с очередью, в куче ли, на стеке ли - главное что они предсказумы. Непредсказуемая может быть рекурсия, но никак не прием информации



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

Цитата
Приходят пакеты из одно порта и ретранслируются в другой (по разным протоколам).
...... Вдруг выходной канал отваливается, а на входе поток не прерываем (так случилось).
DASM
Да не буду я ничего приводить, берете какие-то левые ситуации. Если нет места в буфере - пусть идут все лесом, берем другой контроллер. Еще раз - я спросил причем тут рекрсия, а вы пишите про привести пример. Может тогда приведете пример, как рекурсия поможет сначала ?
Tarbal
Цитата(DASM @ Sep 13 2013, 18:28) *
Да не буду я ничего приводить, берете какие-то левые ситуации. Если нет места в буфере - пусть идут все лесом, берем другой контроллер. Еще раз - я спросил причем тут рекрсия, а вы пишите про привести пример. Может тогда приведете пример, как рекурсия поможет сначала ?


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

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


Цитата(DASM @ Sep 13 2013, 18:28) *
Еще раз - я спросил причем тут рекрсия, а вы пишите про привести пример. Может тогда приведете пример, как рекурсия поможет сначала ?


Посреди улицы разговаривают два одессита. К ним подходит третий. Долго молча слушает, затем резко разворачивается и, уходя, говорит: – Ой! Та не морочьте мне голову…
kolobok0
Цитата(Tarbal @ Sep 13 2013, 17:22) *
..А вот стэк в этом случае побеспредельничает до полного затыкания системы...


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

т.е. в принципе выше правильно прозвучала мысль - что можно и так и так использовать память. и так и так можно убить(либо не убить) всю работоспособность. т.е. в конечном итоге это консерватория - кто как просче и надёжней привык(умеет, знает как) делать.
DASM
Цитата(Tarbal @ Sep 13 2013, 18:48) *
а во-вторых я не знаю как рекурсия поможет. Знаю, что она убьёт содержимое памяти.

"А без рекурсии не получится. Ведь по условию задачи"
Только я противоречие в ваших же словах вижу ? Вы не знаете, как она поможет, но уверены, что без нее не получится ?
Tarbal
Цитата(DASM @ Sep 13 2013, 18:52) *
"А без рекурсии не получится. Ведь по условию задачи"
Только я противоречие в ваших же словах вижу ? Вы не знаете, как она поможет, но уверены, что без нее не получится ?


Нет противоречия. Я никогда не утверждал, что рекурсия поможет, но задача от обсуждения которой вы отказываетесь, поставлена так, что подразумевается рекурсия.
Поскольку задачу ставил не я, то и претензии не ко мне.
demiurg_spb
Цитата(Tarbal @ Sep 13 2013, 17:22) *
Скажите, у вас создалось впечатление, что я уклоняюсь от ответов на какие-то ваши вопросы? Укажите мне на эти вопросы и вы увидите, что ваше впечатление ошибочно. Я предоставлю вам исчерпывающий ответ.
Конечно создаётся, вы ведь так и не смогли сказать, что использование кучи, в приведённом мной примере, на этапе компиляции вам никак не поможет. А про рекурсию - это уже ваши домыслы. Я не предлагал ничего подобного никогда. Извините, но с вами очень трудно разговаривать. Я об одном спрашиваю а вы всё продолжаете быть на своей волне. Разрешите откланяться!

Цитата(DASM @ Sep 13 2013, 18:52) *
Только я противоречие в ваших же словах вижу ? Вы не знаете, как она поможет, но уверены, что без нее не получится ?
+100500 Слишком много додумываний и предположений...
Tarbal
Цитата(demiurg_spb @ Sep 13 2013, 19:03) *
Конечно создаётся, вы ведь так и не смогли сказать, что использование кучи, в приведённом мной примере, на этапе компиляции вам никак не поможет. А про рекурсию - это уже ваши домыслы. Я не предлагал ничего подобного никогда. Извините, но с вами очень трудно разговаривать. Я об одном спрашиваю а вы всё продолжаете быть на своей волне. Разрешите откланяться!

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


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

Цитата(demiurg_spb @ Sep 13 2013, 19:03) *
Разрешите откланяться!


Сливаете?

Цитата(demiurg_spb @ Sep 13 2013, 19:03) *
А про рекурсию - это уже ваши домыслы. Я не предлагал ничего подобного никогда.

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

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

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

Цитата(Tarbal @ Sep 13 2013, 19:24) *
О! Вы появились. Прокоментируйте, пожалуйста мой ответ #17 на ваш #16.



Сливаете?


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

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

Мне кажется Вы слово рекурсия неверно понимаете. А описанную задачу решают с помощью двойной буферизации, пока один буфер принимает — он только принимает.Как заполнен — идет его обработка, а на прием подставляется второй.Совершенно общая практика, начиная от контроллера SPI на верилоге и заканчивая V4L video for Linux.
Tarbal
Цитата(DASM @ Sep 13 2013, 19:42) *
Вобщем malloc использовать стал в микроконтролерах когда у них стало 512 метров ддр внешней. И честно говоря все равно неспокойно. Фрагментация вещь непредсказуемая, но при таких объемах можно считать вероятность отказа незначительной.Это не значит, что нужно отказывать от дин. выделения в мелких, но не родным аллокатором. Говорить о куче в контексте когда все озу килобайт — смешно имхо. Да и не надо было, это же не вебсервер непредсказуемый, да и цена отказа моих программ высоковата, поэтому только стек + статические выделенные буфер ы. Да, никаких вызовов stdlib из прерываний.


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


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

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

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

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

пс, успокойтесь про стек, есть просто заранее выделенные буфера.Это не маллок, это просто и тупо char buff (size)
IgorKossak
Tarbal, смотрите мой комментарий к Вашему предыдущему посту.
Tarbal
Цитата(DASM @ Sep 13 2013, 20:07) *
Не слишком . Это гораздо безопаснее всего остального. И мы коня в вакууме обсуждаем, все это без операционки можно.Знаете присказку, глупцы сложность игнорируют, умные с ней мирятся, а гении — устраняют.Или как то так. Хотите надежно — должно быть просто.

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


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


Если вы полагаете, что вы можете меня чему-то научить, то могу вас заверить это очень маловероятно.
DASM
Динамические на стеке ? Это как ? Учить Вас и не думаю, это, судя по всему, бесполезно sm.gif (конечно же потому, что куда уж мне до таких познаний, а не потому, что можно было подумать)
_Pasha
Цитата(Tarbal @ Sep 13 2013, 22:46) *
СОЗДАНИЕ ДИНАМИЧЕСКИХ МАССИВОВ ПЕРЕМЕННОЙ ДЛИНЫ НА СТЕКЕ ОПАСНАЯ ПРАКТИКА.

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

Что до фрагментации в куче - переход к дескрипторам со встроенным счетчиком ссылок приводит к такому набору
Код
typedef struct _descriptor_t
{
// dsc-table содержит список указателей на области памяти
// при использовании кучи - таблица растет вверх от начала кучи,
// выделяемые области памяти - вниз от конца

  uint_least16_t handle;
  uint_least16_t ref_count;
} descriptor_t, *descriptor_p;
#define DESCRIPTOR(name) descriptor_t name __attribute__((cleanup(force_free_dsc))
descriptor_t alloc_dsc(size_t sz);
void *ref(descriptor_t dsc);// dsc.ref_count +=1; return dsc_table[dsc.handle];
void unref(descriptor_t dsc); //  if(--dsc.ref_count == 0) free_dsc(&dsc);

void free_dsc(descriptor_p dsc);
void force_free_dsc(descriptor_p dsc){dsc->ref_count = 0; free_dsc(dsc);}

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

ps исправил неточности. Если чего пропустил, делайте замечания.
DASM
Цитата(_Pasha @ Sep 14 2013, 08:57) *
Очевидно, что дополнительные накладные расходы не очень тяжелые, поскольку для доступа нужно один раз выделить auto указатель и выполнить ref()
ps исправил неточности. Если чего пропустил, делайте замечания.

Один вопрос - нафига все это ? С такой системой не пройти ни одну сертификацию, она непредсказуема. Для развития мозгов - отлично, не спорю. Мое имхо - памяти должно быть с запасом, а ее расход - предсказуем. Что реализуется статичными массивами и все тут.
ЗЫ из вашего кода вообще ничего неясно. Если реализован сборщик мусора, то и вся Сшная процедура работа с указателями идет лесом, все надо делать либо на переопределенных операторах С++ либо их эмуляцией. Что означает крайне тяжелые расходы по обращению к ним. Легковестность сборщика мусора не в счет - она мало где играет роль.
_Pasha
Цитата(DASM @ Sep 14 2013, 09:50) *
Один вопрос - нафига все это ? С такой системой не пройти ни одну сертификацию, она непредсказуема. Для развития мозгов - отлично, не спорю. Мое имхо - памяти должно быть с запасом, а ее расход - предсказуем. Что реализуется статичными массивами и все тут.

ЗЫ из вашего кода вообще ничего неясно.


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

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

2. Плюсовые аллокаторы идут лесом sm.gif Непонятность выкладок исключительно от непродуманности подхода, сейчас прошло несколько часов - вижу, что сущность типа счетчика ссылок может быть лишней. В голове каша, но она варится sm.gif
Tarbal
Куда ушли те времена, когда требовалось мастерство? Немерянной вычислительной силой можно все что угодно проломить. Зачем нам C++? Давайте сразу Java использовать.
_Pasha
Кстати, понравившийся многим манагер кучи от Zltigo вроде в выделяемом блоке содержал указатель на объект, получивший память? Я ничего не путаю? Ибо, если так, дефрагментация при соблюдении условия - не устраивать эстафету с передачей адреса от указателя к указателю (что действительно редкость) - простое дело. А я тут всякоразно выдумываю...
Tarbal
Цитата(DASM @ Sep 14 2013, 08:33) *
Динамические на стеке ? Это как ? Учить Вас и не думаю, это, судя по всему, бесполезно sm.gif (конечно же потому, что куда уж мне до таких познаний, а не потому, что можно было подумать)

А вы перечитайте второе сообщение треда и увидите, что меня как раз это и напрягло.
demiurg_spb
Цитата(Tarbal @ Sep 16 2013, 03:52) *
А вы перечитайте второе сообщение треда и увидите, что меня как раз это и напрягло.

Да. Это у меня почему то навязчиво лезет слово "динамический" применительно к массиву переменной длины.
Ещё раз за это прошу прощения.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.