OberonCore

RTFM

Блин, а нафига Вам лишь добавление элемента ???
Если у Вас только добавление, которое делается один раз - делайте статический массив максимального размера, и не парьте людям мозги, тем, что неким удвоением какое-то "все" решается.
Сам смысл динамического изменения размера - заключается в возможности освобождении ресурса, для использования его же в другом месте.
Ниоткуда оно не всплылО. Оно всегда было в исходной постановке. Независимо от того, понимает это кто-то, или нет.
Это та самая "простая вещь", которую, как оказывается - хрен объяснишь

И Вас - тоже.
И о многом, в Вашем отношении, начинаю догадываться...

Проверьте, делая добавки к 100М-тексту (бог с ним, с гигом, если Ваша лично винда его не выделяет)
Убивать таких знатоков, блин.
Смотрим в System.pas: _LStrCat -> _LStrSetLength -> _ReallocMem
Специально отмечу, что "смотреть много раз", и понимать написанное - не всегда одно и то же.

Обязательно
Начните с того, что именно Вы лично понимаете под реэпингом. Если уж (оказывается!!!) при данной операции указатель меняется.
И откройте попутно глаза: меняется ли указатель при выполнении SetLength из Mt... И как они докатились до такого "кошмара"

Хм...
Причем здесь за рыбу деньги - не пойму никак. Это не чудо, это база... Вот только не вспомню никак: в 386-м, или в 486-м появившаяся... давно было

Но ДА, такая постановка возможна. Например, у меня любимый камень - Atmega-8
Там всего 1К на борту - какая нафиг страничная память.
Ну, скажем, стоит сегодня у меня он в самом LPT-разъеме, и занимается приемом пакетных данных с компа, и отправляет по I2C (у них это называется TWI-интерфейс) в мою маленькую системку.
Т.е., это буфер FIFO. И его емкость мне не маловажна, чтобы пижонить с удвоениями. И быстродействие - тоже, чтобы пижонить с копированиями.
А ведь у меня сеть-то "многомастерная". Т.е., нормальная жизнь (кончил передавать один пакет - начинай передавать другой), может быть порушена необходимостью уже принимать пакеты от железа.
И куды девать данные этих пакетов ???
Строить динамическую память (с реаллокацией методом копирования) ???
Ага, щаз
Ну придумал я чего-то там... пишу в свободное место FIFO (закольцованный массив), в обратном порядке, от того "хвоста" где данные уже использованы (переданы в сеть)

Мораль - выпрыгни из трусов, но обойдись без копирования Рефракторинг задачи способен на многое

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

И вам того же.
???
По моему не в этом совсем, а в невозможности выделить неизвестное их (ресурсов) количество заранее...
Просто оно реализуется аналогично, понимает это кто-то, или нет.
А вы дальше, в ReallocMem смотрели?
(Специально отмечу, что "смотреть много раз", и понимать написанное - не всегда одно и то же. )
Мепинг - отображение логических адресов на физические. Ремепинг - изменение этого отображения. Ремепинг применяется как для изменения логического адреса без изменения физического (например MemoryMappedFiles), так и для изменения физического без изменения логического (например swap-файл).
Открываю вам глаза - меняется! Точнее может менятся. И кстати, по секрету, он (SetLength из Mt) ТОЖЕ копирует массив. А как они "докатились до такого "кошмара"" спросите у авторов. Я это кошмаром не считаю.

PS: В коде мне кажется лушче использовать не "ручное" создание копии массива и его копирование, а использование именно SetLength из Mt по двум причинам:
1. Он написан более оптимально в связи с использованием оптимизированной SYSTEM.MOVE.
2. Он може быть в будущем переписан под другую платформу еще более оптимально, например с тем же ремапингом, если это возможно.

И понеслась...

Замечу, что начавшийся спор товарищей Galkov и Алексей Елин удалился от исходной темы "аналог new ArrayList() (.NET)".

Если эта "дискуссия" вам действительно необходима --- определитесь с темой (ЛС) и выделим...

Мне показалось, что тема достаточно интересна (наверное, потому что здесь у меня пробел в знаниях ).
Так что, IMHO, выделить ее стоит.
А вот ссориться, конечно, не надо. Расхождение во мнениях -- не причина.

А нужна ли там вообще реаллокация, если даже отказаться от дополнительной памяти в буфере FIFO?
Ведь, вероятно, длина пакета ограничена.

Как бы не очень понял вопроса....
О чем я говорил: мне заранее неизвестно ни количество возможных пакетов, ни их длина. Ну поперли себе. Аппаратная возможность "заморозить" физическую линию - есть (I2C все-таки). Но пусть это будет (если у меня голова на плечах есть) только когда действительно ВСЯ память кончится...
Тем более, что и ограничений на длину у меня и нет, в общем-то. Скажем, "траектория движения" (это координатный стол) - очень длинная может быть.
Есть тупой (в смысле - шаблонный) способ: ничего знать не хочу, все и без меня придумано - получили хэдер пакета, реаллоцируем память (хотя не факт, что из него можно длину пакета получить).

Но в моей конкретной задаче это можно сделать более адекватно, без резервирования неизвестно чего и сколько...
И вот единственное, чего я хотел всем этим сказать - почти всегда чего-то можно придумать. Побудительный мотив - да ну его нафиг все эти релокации (особенно, если они сопровождаются "копированием" ), когда у тебя 1К на борту.
Конечно, это персональная заморочка.
Какой результат: у меня система собрана на 50-ти рублевых камнях, а буржуины для этого adsp (точно не помню, порядка 100$) используют.

Так я возьму и посмотрю, упертый Вы наш
Джефри РИХТЕР "Создание эффективных WIN32-приложений", ЧАСТЬ III УПРАВЛЕНИЕ ПАМЯТЬЮ, ГЛАВА 13
Подраздел: "Как адресное пространство разбивается на разделы", 4-я строка, 2-й столбец в сводной таблице
Для кода и данных пользовательского режима: 0x00010000-0x7FFEFFFF

Утверждение: в этот диапазон 1 гиг влазит, а два - нет.
А Вы какими наскальными надписями руководствовались


Да.
А Вы попробовали добавлять "хвостики" к 100М-строке
Впрочем, удобнее делать SetLength для динамических массивов.
Заодно сравнить с одноименной операцией в Mt - там-то сто пудовое копирование.


Ай молодец!
Теперь следующий шаг: как это стыкуется с Вашим же утверждением Продолжайте объяснения. Дальше


Зачем, я знаю ответ.
И именно зная его, и поднял вопрос порочности копирования.
По большому счету, это диспут о правильности идеи "изоляционизма"


Более оптимально это использование HeapReAlloc - только оси под силу т.н. ремэпинг. Вместе, раздельно, супер-пупер-хитромудро - десятый разговор. Хотя и не простой, парой простеньких идеек на ограничится.
Собственно, ровно это я и говорил.
И к чему все предыдущие заморочки - перестал понимать, в связи с этим.

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

Мой опыт это не подтверждает. В моей предметной области, конечно.

Согласен.
Хотел только добавить, что порой может найтись и 2-е, и 3-е решение.

У меня есть смутное воспоминание, что архитектура с ассоциативной памятью рассматривалась в старой книге Г.Майерса "Архитектура современных ЭВМ".
Сходу трудно оценить возможные плюсы и минусы такого подхода.

Думал, думал и наконец осознал: идея дискриптор+смещение (см. мой пост выше) - полная чушь. Это не более чем эквивалент бОльшей адресации.
Даже 64 бит достаточно чтобы НАВСЕГДА забыть о нехватке памяти при увеличении... просто надо выделять каждый новый пойнтер по границе в максимальный размер непрерывного блока:

Например макс размер блока 4Г... и все!
Это будет эквивалентно 4Г(32бит) смещение + 4Г(32бит) дескриптор. (32+32=64)

Или макс блок 1Тб - 40 бит (смещение и макс. непрерывная область в 1Террабайт) +24 бит дескриптор (16 миллионов). (40+24=64).

Но возможнжо и другое соотношение.

А если адресация 128 бит...

Да, если смотреть дальше, упираемся в RtlReAllocateHeap, которая сводится к
RtlAllocateHeap, memmove, RtlFreeHeap.

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

А как обстоят дела с менеджером памяти в ББ?