Недоиспользование динамических типов в Дельфи?

← →
test © (2009-03-04 11:45) [40]

Marser © (04.03.09 10:52) [35]
Я эт про автора, у него похоже динамические структуры поперек мозга застряли

← →
It's not me (2009-03-04 11:48) [41]

> У каждого подхода есть свои + и -.

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

> 1. Выделение памяти под локальную переменную - статический
> массив проходит быстрее

это ты про стек говоришь? Я уже рассматривал данный вариант.

> 2. Вопрос интероперабельности с не Delphi кодом динамических
> массивов(да и вообще всех управляемых типов) потребует дополнительных
> затрат

не понял.

← →
clickmaker © (2009-03-04 11:52) [42]

> И в данной ситуации не вижу плюсов у статических массивов

+ такой, что нет накладных расходов на выделение памяти и отслеживания ссылок на переменную.

← →
Сергей М. © (2009-03-04 11:56) [43]

> это хоть чем-то обосновано

Да, обосновано - конкретным контекстом их применения.

А ты вырвал свой шматок кода из какого-то никому кроме тебя неведомого контекста и считаешь что тем самым "обосновал" решение с дин.массивом.

← →
oxffff © (2009-03-04 12:09) [44]

> > 1. Выделение памяти под локальную переменную - статический
>
> > массив проходит быстрее
>
> это ты про стек говоришь? Я уже рассматривал данный вариант.
>

Где рассматривал? Ссылку на вашу работу можно?
Существуют способы динамического выделения памяти на стеке при условии определенных правилах.
Ты их рассматривал?

> > 2. Вопрос интероперабельности с не Delphi кодом динамических
>
> > массивов(да и вообще всех управляемых типов) потребует
> дополнительных
> > затрат
>
> не понял.

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

← →
KSergey © (2009-03-04 12:23) [45]

> oxffff © (04.03.09 12:09) [44]
>>> 2. Вопрос интероперабельности
>> не понял.
> могут не содержать такой семантический эквивалент

Из серии "кто уже и так знает - тот поймет" :)

PS
Все правильно, пусть мозг включит наконец.
А то ему пишут-пишут плюсы/минусы, а он заладил как попка-попугай "не вижу, не вижу". И сам одно и тоже талдычит всю ветку совершенно не обращая внимания на ответы.

← →
KSergey © (2009-03-04 12:27) [46]

> It"s not me (04.03.09 11:48) [41]
> > У каждого подхода есть свои + и -.
> вот именно. И в данной ситуации не вижу плюсов у статических массивов.

Их вполне может и не быть. Ну написал кто-то вот так, оно работет, стабильно. Все довольны.
Солнце вон тоже всходит и заходит. "А есть ли в этом плюсы и минусы?"

← →
It's not me (2009-03-04 12:44) [47]

> Где рассматривал?

пост [16]

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

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

Я вообще НИ РАЗУ не встречал ситуаций, когда память выделяется в одном модуле (Exe / DLL), а высвобождается в другом. Так никто никогда не делает. Если ты имеешь в виду ВНЕШНИЕ языки.

> + такой, что нет накладных расходов на выделение памяти
> и отслеживания ссылок на переменную

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

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

Что касается отслеживания ссылок... А где там накладные расходы? Только при присвоении массивов, в этом случае у статических массивов еще больше расходов - происходит полное копирование элементов. Хочешь добиться поведения как у статических массивов? Пиши: DynArray1 = Copy(DynArray2... ) - наздоровье. В любом случае динамические массивы полностью перекрывают возможности статических массивов.

И там где используются статические массивы - ВСЕГДА можно использовать динамические, причем так, что затраты будут одинаковые. Это если размер данных заранее известен. А если размер данных неизвестен - то тут динамические массивы позволят только выиграть в скорости и ресурсах.

← →
Ega23 © (2009-03-04 12:54) [48]

А народ всё ведётся и ведётся.... И народ-то не глупый.... :)

← →
clickmaker © (2009-03-04 12:55) [49]

> Под статический массив один фиг нужна память, она будет
> или выделена неявно в куче

а не в сегменте DATA?

← →
clickmaker © (2009-03-04 13:01) [50]

вернее, в BSS

> А если размер данных неизвестен - то тут динамические массивы
> позволят только выиграть в скорости и ресурсах.

а как в этом случае можно вообще использовать статические массивы?
К тому же, скорость зависит от реализации конкретного менеджера памяти.
Вот автор ФАРа - Рошал - к примеру, говорил, что они принципиально компилят его на борладн с++, потому что по каким-то тестам его менеджер обогнал майкрософтовский

← →
Сергей М. © (2009-03-04 13:29) [51]

> Я вообще НИ РАЗУ не встречал ситуаций, когда память выделяется
> в одном модуле (Exe / DLL), а высвобождается в другом. Так
> никто никогда не делает. Если ты имеешь в виду ВНЕШНИЕ языки

Зашибись аргумент: "так никто не делает, потому что Я НИ РАЗУ НЕ ВСТРЕЧАЛ"

)

p.s.

О непобедимости в споре
(религиозная аргументация)

- Земля имеет форму чайника носиком внутрь!
- Вы чего, обалдели?!
- А по-вашему лучше, чтобы Земля имела форму задницы, как нас учат Марсианские Клопогрызы по космическим лучам?!
- Но почему форму задницы?!
- Да потому что Марсианские Клопогрызы об этом говорят целыми днями! Они уже все космические лучи захватили! Вы разве не видите?!
- Да не слушайте вы этих космических лучей!
- Нет! Мы не можем не слушать, как они нас развращают! Только мы с нашей Идеей Великого Чайника можем противостоять Марсианским Клопогрызам!
- Ну и противостоите на здоровье, кто же вам мешает. Вам для этого и полигон выделили. Чего ко мне-то пристали?
- Идёт война миров! Или чайник, или задница! Третьего не дано!
- Да как же не дано? Земля имеет форму сплюснутого сфероида.
- Значит, вы за Марсианских Клопогрызов? А может, даже скрытый Клопогрыз! Ведь от сфероида до задницы один шаг!
- Да не Клопогрыз я! Какое мне вообще дело до каких-то Марсианских Клопогрызов?!
- А вы хотите жить в заднице?
- Нет, не хочу.
- Что и требовалось доказать. Земля имеет форму чайника носиком внутрь!

← →
KSergey © (2009-03-04 13:31) [52]

снова терминологический спор.

It"s not me, что есть динамический и статический массив? В примерах, плиз.

← →
Плохиш © (2009-03-04 13:40) [53]

Прикольно, у деток новый холивор :-))

← →
test © (2009-03-04 13:43) [54]

Сергей М. © (04.03.09 13:29) [51]
Это он похоже и есть ))
Автор темы "используем пустые try..except..end все равно все ошибки не отловишь"))

← →
It's not me (2009-03-04 14:02) [55]

> А народ всё ведётся и ведётся.... И народ-то не глупый..
> .. :)

Олежка, я тебе обязательно памятник поставлю как самому лучшему пинкертону на форуме. Ну надо же, все ведутся, один ты смог определить, что все это развод. Какой умный развод! Я уже запарился деньги со счета снимать.

> вернее, в BSS

не знаю, что такое BSS... То есть, память для статического массива все таки выделяется быстрее и есть принципиальные отличия от GetMem / SetLength ?

> а как в этом случае можно вообще использовать статические
> массивы?

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

Там приведен пример с UDP дейтаграммой. Ты же не знаешь ее размера, какая она прийдет. Но при этом знаешь возможный максимальный размер - 64 кбайт, и можно использовать статику на 64 кбайт.

Еще один пример - определение пути. Ты ведь не знаешь длину какого-то файлового пути, но при этом знаешь, что он не может быть более MAX_PATH. Это как пример просто.

> Зашибись аргумент: "так никто не делает, потому что Я НИ
> РАЗУ НЕ ВСТРЕЧАЛ"

я такого нигде не говорил. Это твое намеренное искажение моих слов, один только вопрос остается - зачем намеренно искажать мои слова? Видимо, чтобы сделать вывод, что я дурак. Поздравляю, получается как всегда гениально.

> It"s not me, что есть динамический и статический массив?
> В примерах, плиз.

статический: StatArray: array[0..65545] of byte;
динамический: DynArray: array of byte;

← →
Сергей М. © (2009-03-04 14:11) [56]

> я такого нигде не говорил

Говорил-говорил, не отнекивайся)

← →
clickmaker © (2009-03-04 14:13) [57]

> не знаю, что такое BSS... То есть, память для статического
> массива все таки выделяется быстрее и есть принципиальные
> отличия от GetMem / SetLength ?

она выделяется один раз при старте
BSS - для неинициализированных данных
DATA - для инициализированных и констант

← →
KSergey © (2009-03-04 14:19) [58]

> It"s not me (04.03.09 14:02) [55]
> статический: StatArray: array[0..65545] of byte;
> динамический: DynArray: array of byte;

Очень замечательно.
Теперь осталось прикинуть какие операции нужны для создания/уничтожения этих массивов - и все станет понятно. Можно свериться с ассемблером, для точности.

← →
KSergey © (2009-03-04 14:22) [59]

> clickmaker © (04.03.09 14:13) [57]
> она выделяется один раз при старте

В нотации автора - вообще только на стеке. У него весьма узкое толкование стат. массивов.
В общем случае оно шире. Даже DynArray: array of byte; в глобальной видимости тоже можно считат стат. массивом при условии, что память под него выделяется однажды при старте программы; тогда накладные расходы на это дело в сравнении со временем работы программы - ничтожны.

← →
oxffff © (2009-03-04 14:37) [60]

> It"s not me (04.03.09 12:44) [47]
>
> > Где рассматривал?
>
> пост [16]
>
>
> > Внешние языки могут не содержать такой семантический эквивалент
>
> > типа(динамический массив). Хотя могут быть совместимы
> для
> > использования, но несовместимы для управления временнем
>
> > жизни(ссылок),
>
> вообще непонятно, что ты имеешь в виду. Если говорить о
> внешних языках, то они в любом случае несовместимы в вопросах
> выделения / освобождения памяти для какой бы то ни было
> переменной вообще, и это не касается ни конкретно статических,
> ни конкретно динамических массивов.

Не нужно касаться вопросов работы кучи(хотя и и этот вопрос можно решить), у типа есть контракт по его использованию например Добавить_ссылку, Удалить_ссылку на экземпляр.
Внешние просто следуют ему.

> Под статический массив один фиг нужна память, она будет
> или выделена неявно в куче (какая при этом разница по сравнению
> с явным выделением памяти в куче?!) или выделена в стеке.

Смотрел функции? Сравни скорость.

function StackAlloc(Size: Integer): Pointer; register;
asm
POP ECX { return address }
MOV EDX, ESP
ADD EAX, 3
AND EAX, not 3 // round up to keep ESP dword aligned
CMP EAX, 4092
JLE @@2
@@1:
SUB ESP, 4092
PUSH EAX { make sure we touch guard page, to grow stack }
SUB EAX, 4096
JNS @@1
ADD EAX, 4096
@@2:
SUB ESP, EAX
MOV EAX, ESP { function result = low memory address of block }
PUSH EDX { save original SP, for cleanup }
MOV EDX, ESP
SUB EDX, 4
PUSH EDX { save current SP, for sanity check (sp = [sp]) }
PUSH ECX { return to caller }
end;

{ StackFree pops the memory allocated by StackAlloc off the stack.
- Calling StackFree is optional - SP will be restored when the calling routine
exits, but it"s a good idea to free the stack allocated memory ASAP anyway.
- StackFree must be called in the same stack context as StackAlloc - not in
a subroutine or finally block.
- Multiple StackFree calls must occur in reverse order of their corresponding
StackAlloc calls.
- Built-in sanity checks guarantee that an improper call to StackFree will not
corrupt the stack. Worst case is that the stack block is not released until
the calling routine exits. }
procedure StackFree(P: Pointer); register;
asm
POP ECX { return address }
MOV EDX, DWORD PTR [ESP]
SUB EAX, 8
CMP EDX, ESP { sanity check #1 (SP = [SP]) }
JNE @@1
CMP EDX, EAX { sanity check #2 (P = this stack block) }
JNE @@1
MOV ESP, DWORD PTR [ESP+4] { restore previous SP }
@@1:
PUSH ECX { return to caller }
end;

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

Кто выделил память в кучи для стека, виртуальная машина?

← →
It's not me (2009-03-04 15:06) [61]

> Говорил-говорил, не отнекивайся)

тогда цитату, пожалуйста, приведи.
Естественно, ты цитату привести не сможешь, но будешь продолжать уверять, что я это говорил. Это мне всегда нравится.

> она выделяется один раз при старте

при старте чего, приложения? Если это переменная метода или поле класса, как она может выделиться, ведь неизвестно сколько раз будут вызываться метод (рекурсия), неизвестно сколько экземпляров класса будет создано?

Ты, вероятно, говоришь исключительно о глобальных переменных. О глобальных статических массивах. А речь я считаю не о том.

> В общем случае оно шире. Даже DynArray: array of byte; в
> глобальной видимости тоже можно считат стат. массивом при
> условии

вот именно, что можно его фактически считать статическим массивом. И это не минус по отношению к реально статическому массиву.

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

> Смотрел функции? Сравни скорость.

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

> Кто выделил память в кучи для стека, виртуальная машина?

не знаю. Тонкости не знаю. Я так понимаю, что для каждого потока винда создает стек. или менеджер памяти дельфовый создает стек... В общем, не знаю я.
Но насколько я понимаю, стек - это просто заранее выделенный (зарезервированный) участок памяти. "Выделять память" в таком участке, конечно, проще, просто сдвигая указатель, ибо память уже заранее фактически была выделена.

← →
Sha © (2009-03-04 15:12) [62]

> It"s not me (03.03.09 14:56)

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

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

← →
Сергей М. © (2009-03-04 15:13) [63]

> Это мне всегда нравится

Нравится ? Заполучи еще раз !)

> It"s not me (04.03.09 12:44) [47]
> ..
> Я вообще НИ РАЗУ не встречал ситуаций, когда память выделяется
> в одном модуле (Exe / DLL), а высвобождается в другом. Так
> никто никогда не делает.

Так вот в моей фразе

> Зашибись аргумент: "так никто не делает, потому что Я НИ
> РАЗУ НЕ ВСТРЕЧАЛ"

квинтессенция этого сногосшибательного аргумента - смысл тот же, только букаф меньше)

← →
test © (2009-03-04 15:22) [64]

It"s not me (04.03.09 15:06) [61]
Я НИ РАЗУ НЕ ВСТРЕЧАЛ (рус.) перевод на Паскаль*Русский

Хрен где встретишь код:

function Answer: TByteDynArray;
begin
SetLengthh(Result, Sock.Len);
Sock.WriteBuf(Result[0], Length(Result) );
end;

Зато можно встретить код аля:

cMaxUdpLen = 64kb;

TUdpBuffer = array[0..cMaxUdpLen-1] of byte;

function Answer(out Buf: TUdpBuffer): integer;
begin
Result := Sock.Len;
Sock.WriteBuf(Buf[0], Result );
end;

← →
clickmaker © (2009-03-04 15:28) [65]

> Я вообще НИ РАЗУ не встречал ситуаций, когда память выделяется
> в одном модуле (Exe / DLL), а высвобождается в другом. Так
> никто никогда не делает

например StrDup из slwapi.dll, или FormatMessage из kernel32

← →
It's not me (2009-03-04 15:34) [66]

> В первом варианте менеджер ...

Sha, да, ты прав абсолютно.. Я почему-то об этом не подумал. Действительно, ведь эта функция наверняка будет вызвана не один раз, а много. И очень вероятно, что будет передаваться один и тот же буфер от вызова к вызову... И чем больше вызовов, тем более эффективен будет стат. массив... Хотя на одном вызове выиграет динамический массив...

Спасибо! Тема закрыта.

← →
Marser © (2009-03-04 15:34) [67]

> динамический: DynArray: array of byte;

Вообще-то это называется открытым массивом, а с динамическими автор, наверное, никогда и не работал :-))

← →
KSergey © (2009-03-04 15:35) [68]

> test © (04.03.09 15:22) [64]
> Хрен где встретишь код:
> function Answer: TByteDynArray;
>
> Зато можно встретить код аля:
> function Answer(out Buf: TUdpBuffer): integer;

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

← →
It's not me (2009-03-04 15:36) [69]

> квинтессенция этого сногосшибательного аргумента - смысл
> тот же, только букаф меньше)

попробуй найти различие между двумя фразами:

"У Антона были синие глаза. Он был ярым поклонником коммунистического движения"

отличие от:

У Антона были синие глаза, потому что он был поклонником коммунистического движения".

Так вот мой вариант - первый. А твой переформулированный вариант - второй. На мой взгляд разница очевидна. Если тебе не очевидна - ну и пофик.

Автор, уже давно пора понять, что нет абсолютно ничего принципиально плохого в дин. массивах и в стат. массивах.
Можно применять и то и это, на довольность заказчика вне контекста это не влияет.

Насколько я помню из своего босоногого детства, чтобы использовать динамический массив, мы должны объявить тип-указатель на массив до огого каких пределов ($FFFF по-скромному), а затем уж под него выделить памяти ровно столько, сколько нам нужно. Вот это и есть динамический массив, это было в Паскале столько, сколько там были указатели, а открытые массивы лишь в Делфи 4 появились....

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

← →
It's not me (2009-03-04 15:50) [73]

> Вообще-то это называется открытым массивом, а с динамическими
> автор, наверное, никогда и не работал :-))

> чтобы использовать динамический массив, мы должны объявить
> тип-указатель на массив до огого каких пределов ($FFFF по-
> скромному), а затем уж под него выделить памяти ровно столько,
> сколько нам нужно

ты пишешь сейчас такой бред, что просто слов нету. Еще и пытаешься автора в чем-то обвинять. А ведь наверняка уверен в своей правоте.

Так вот понятие "открытый" массив применимо исключительно к понятиям объявления функций или метода.

Вот это: var a: array of byte - динамический массив. Понятия "открытый" массив при объявлении переменных просто нету. Только в объявлениях функций / процедур / методов, например:

procedure Test(A: array of byte) - вот тут можно сказать, что процедура Test принимает ОТКРЫТЫЙ массив в качестве параметра A.

Здесь же:

type TDynArray = array of byte; procedure Test(A: TDynArray)

процедура Test принимает ДИНАМИЧЕСКИЙ массив в качестве параметра A.

> на массив до огого каких пределов ($FFFF по-скромному),

абсолютное путаница. Это лишь реализация способа адресации неизвестного (потенциально огромного) массива элементов. И размер объявляется так, чтобы такой массив ТЕОРЕТИЧЕСКИ мог существовать в ВАП процесса, иначе дельфи не скомпилит код. Но реально такой массив никогда не создается, конечно, только указатель на него.

В общем, это принцип TList.

> Григорьев Антон © (04.03.09 15:41) [72]
> потому что для каждого обращения к элементу такого массива требуется неявное разыменование указателя,

не очень понимаю про "разименование" в терминах скомпилированного кода (вроде это чистая абстракция для объяснения в терминах языка высокого уровня?), но сейчас специально посмотрел и с удивлением обнаружил, что для строчки вида bb[2] := 5; в случае стат. массива генерится 1 команда ассемблера, а в случае дин. массива - 2, т.к. надо еще прочитать значение указателя на дин массив; в случае стат массива он уже всегда имеется. Вот бы не подумал...

> It"s not me (04.03.09 15:36) [69]

Ты давай уже оглобли не разворачивай)

Так делают, и факты тебе уже привели ! А маловато будет - еще полну котомку фактов тебе понапхаем)

Суслик-то есть, даже если ты его не видишь и видеть не желаешь)

← →
Sapersky (2009-03-04 16:32) [76]

чтобы использовать динамический массив, мы должны объявить тип-указатель на массив до огого каких пределов ($FFFF по-скромному), а затем уж под него выделить памяти ровно столько, сколько нам нужно. Вот это и есть динамический массив

Ну если уж в Борланде назвали array of <тип> динамическим массивом - то лучше их так и называть, ИМХО (открытые тоже есть, но это другое).
А то, про что вы пишете я называю "массив-указатель". Это же типизированный указатель по сути.

в случае стат. массива генерится 1 команда ассемблера, а в случае дин. массива - 2, т.к. надо еще прочитать значение указателя на дин массив

Компилятор опасается, что массив может быть в любой момент переаллоцирован и указатель "уедет". Но если передавать массив в функцию как const, компилятор может использовать одну команду вида mov [reg1 + reg2 * elSize]. Что, кстати, тоже выглядит избыточно - const-массив точно никуда не "убежит", можно было бы использовать "простой" mov. Не знаю, почему так сделали.
Но в общем, всё это ловля блох. В реальных проектах тормозят не обращения к элементу. Разве что у многомерных дин. массивов это может быть заметно, по причине сложной внутренней структуры.

>
> абсолютное путаница. Это лишь реализация способа адресации
> неизвестного (потенциально огромного) массива элементов.
> И размер объявляется так, чтобы такой массив ТЕОРЕТИЧЕСКИ
> мог существовать в ВАП процесса, иначе дельфи не скомпилит
> код. Но реально такой массив никогда не создается, конечно,
> только указатель на него.

И кто ещё пишет бред :-)

← →
It's not me (2009-03-04 16:56) [78]

> в случае стат массива он уже всегда имеется. Вот бы не подумал.
> ..

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

> Так делают, и факты тебе уже привели !

Я не считаю приведенный пример доказательством, что так делают. Один фиг:

The caller should use the LocalFree function to free the buffer when it is no longer needed.

По факту все равно память что освобождается, что выделяется в модуле kernell.dll - согласен?
Я тоже самое могу сделать в своем модуле, выделить память и обязать внешний источник вызывать мою MyFreeMemory, в которой уже и будет освобождение памяти. Как это трактовать? Я трактую, что память освобождается все равно в МОЕМ модуле, хотя и по приказу извне. Но я понимаю, что это философский вопрос, поэтому предлагаю не разворачивать бесполезную дискуссию.

> И кто ещё пишет бред :-)

ты пишешь бред. именно ты продемонстрировал полное незнание понятий что такое динамический и что такое открытый массив.

Попробуй объявить такой тип в дельфи:

TTestArray = array[1..High(Integer)+1] of byte;

и посмотри, почему будет ошибка.

А теперь попробуй объявить:

TTestArray = array[1..High(Integer)] of byte;

и подумай почему получилось. Почему объявление типа массива, который занял бы в ВАП 2 ГБайт (столько выделяется в ВАП для данных приложения) можео объявить, а 2 Гбайт плюс 1 байт уже нельзя. По-моему, разжевал для самых маленьких.

> Sapersky (04.03.09 16:32) [76]
> const-массив точно никуда не "убежит", можно было бы использовать "простой" mov.

Регистров-то ограниченное число, в отличии от памяти :)
Впрочем, я смотрел с отключенной оптимизацией, может все было бы сильно иначе.

> It"s not me (04.03.09 16:56) [78]
> вот видишь как оно. Я тоже этого не знал, но подозревал, что что-то такое есть. И для тебя ветка стала полезной.

Бесполезной.
Я заглядывал в профайлер. Мне хватило, написанное же - оно про блох.

Недоиспользование динамических типов в Дельфи? Найти похожие ветки