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

[Navovvol]

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

[DASM]

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

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

[Tarbal]

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

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

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


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

[_Pasha]

СОЗДАНИЕ ДИНАМИЧЕСКИХ МАССИВОВ ПЕРЕМЕННОЙ ДЛИНЫ НА СТЕКЕ ОПАСНАЯ ПРАКТИКА.

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 исправил неточности. Если чего пропустил, делайте замечания.

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

[DASM]

Очевидно, что дополнительные накладные расходы не очень тяжелые, поскольку для доступа нужно один раз выделить auto указатель и выполнить ref()
ps исправил неточности. Если чего пропустил, делайте замечания.

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

[_Pasha]

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

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

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

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

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

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