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

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

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

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


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

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

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

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

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

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

Сообщение отредактировал _Pasha - Sep 14 2013, 05:15

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

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

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

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

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

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

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

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

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