Забыл уточнить -- виртуальной, не факт, что это будет непрерывная физическая память.
------------ Дoбавленo в 15.31:
Продолжение исследований. Схема на рассыпухе с возможностью наращивать и сокращать размер массива. Но надо обновить c SVN компонент MT_MTArray, куда добавлен метод doDelete

1) Аналогично
2) Имелся в виду конкретный товарищ: WinAPI.HeapRealloc.
Юридически: никто не утвержал, что он копирует, или НЕ копирует.

Вывод: утверждение, что "Товарищ .... делает то же самое " не является логически доказуемым.
Верным таки является мое: "НЕ ФАКТ, что копируется"
Ну а я бы не стал делать ставку на то, что они все там дураки.
Такое быть конечно может,но ставку делать не стал бы...

В принципе, вопрос важный в теоретическом смысле: нужны ли встроенные в некий ЯВУ всякие там "SetLength-ы", или это личное дело строителей библиотек... Холиваров на эту тему хватает...
Ну согласись, копировать, или иметь халявную копию нескольких гигов - может оказаться не всем безразлично.

Где про это написано. А по моему -Факт, что это будет непрерывная физическая память.

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

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

А как тогда вот это объяснить -- http://www.delphimaster.ru/cgi-bin/forum.pl?id=1307429189&n=0
------------ Дoбавленo в 17.28:

Как ты читаешь, понятия не имею


------------ Дoбавленo в 17.34:

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

Читаю я нормально.

А че тогда так отвечаешь, повторяя то, что было написано выше

Есть менеджер памяти Windows и не надо ему мешать делать своё дело.

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

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

Ага, особенно, когда системе ее не хватает, и она начинает сбрасывать приложения кусками на диск. Если бы приложению всегда выделялась непрерывная память, то не существовало бы понятий динамического выделения памяти и виртуального адресного пространства
------------ Дoбавленo в 19.46:
Вот познавательная статейка про выделение памяти -- http://www.codenet.ru/progr/os/RAM/RAM-4.php
Кстати, "Куча с пониженной фрагментацией" и есть табличный кластерный массив с фиксированной длиной элемента, и как видно, не является непрерывной памятью, а именно кластерным распределением участков

Как ты говоришь - не смеши мои тапочки ?Из цикла - Одна баба сказала...
------------ Дoбавленo в 20.30:
Если "автор не знает", то дальше даже читать не стоит.(ударение в последнм слове можно на любую гласную)

[flood]Очень интересная тема, и ссылки. Спасибо![/flood]

login,