Форум: "Потрепаться";
Текущий архив: 2004.05.30;
Скачать: [xml.tar.bz2];
ВнизДинамический объект. Найти похожие ветки
← →
Algol (2004-05-10 11:37) [40]Вот тоже любопытный результат:
type
TMyClass=class
v:Integer;
end;
....
procedure TForm1.Button1Click(Sender: TObject);
var V,V1:TMyClass;
begin
V:=TMyClass.Create;
V.v:=1111111;
if IsNotInvalidPointer(V) then
showMessage(intToStr(V.V));
if IsNotInvalidPointer(V) then
showMessage(intToStr(V.V));
end;
← →
default © (2004-05-10 12:03) [41]казалось бы что проще: указатель на объект указывает на младший байт адреса VMT(нам вообще пофигу на что - главно что указывает на байт памяти выделенный менеджером памяти Delphi во время выполнения) и когда объект разрушен - память освобождена и попытка обращения к ней(допустим к байту описанному выше) через битый указатель приведёт к AV-у и дело с концом...но никакого AV-а нет!, память не освобождается сразу что-ли? или компилятор настолько умён что ожидает создания нескольких экзмемпляров данного типа приложением и не освобождает выделенную память
и когда будет попытка создать новый экз-ар достаточно будет вызвать код конст-ра для инициализации и передать "битый" указатель соискателю, вопрос в том сколько придётся ждать, а память будет "висеть" попусту, делает интервалы ожидания и освобождает память в случае их истечения, вряд-ли... многие бы это заметили...хотя...
← →
Тимохов © (2004-05-10 12:07) [42]
> default © (10.05.04 12:03) [41]
не всегда обращение по битому указателю дает av.
можно создать объект, отдестроить, обратится к полю - все будет ок. Если же обратится к методу - скорее всего будет av.
Обращение к битой (в вашем понимании) памяти не приводит к ошибке, т.к. с точки зрения операционной системы память не фига не битая - она зарезирвирована менеджером памяти дельфи.
Другой вопрос, если вы попытаетесь обратится к незарезирвированной менеджером памяти области, то точно будет av.
Попусту ничего не висит.
← →
default © (2004-05-10 12:18) [43]Тимохов © (10.05.04 12:07) [42]
"она зарезирвирована менеджером памяти дельфи."
значит память не освоб-ся, почему?
понятно что надо копать в мен-ре Delphi, но лень
← →
Тимохов © (2004-05-10 12:25) [44]
> default © (10.05.04 12:18) [43]
Скажу честно - я сам менеджер памяти пытался копать несколько раз, но все терпел неудачу, т.к. на тот момент не обладал знаниями об организации памяти в windows.
Теперь вроде как обладаю (немного).
Могу предположить, что сначала менеджер резервирует память (резервирование), потом по мере необходимости передает зарезервированные куски физической памяти (выделение), по мере потери необходимости в памяти меденжер не спишит переводить выделенную память в резервированную - может еще понадобится.
Наверное, ошибаюсь в чем-то, но имхо так было бы логично.
По крайней мере на предположение, что менеджер дельфи не срязу делает uncommit памяти (т.е. из выделенной памяти делает просто резервированную) при freemem наталкивает тот факт, что после freemem часто можно обращаться к освобожденному куску без av. Если бы дельфи сразу отдавал память системе, то точно был бы av.
Вроде так...
Пойду еще почитаю :)
← →
McSimm © (2004-05-10 12:29) [45]С трудом сдержался...
:о)
От аббревиатуры ?
:))
← →
Тимохов © (2004-05-10 12:32) [46]
> McSimm © (10.05.04 12:29) [45]
а может от двуточий, троеточий и такдалееточий?
:)))
← →
default © (2004-05-10 13:03) [47]"Третий, и последний, механизм управления памятью — динамически распределяемые области памяти,
или кучи (heaps). Они весьма удобны при создании множества не больших блоков данных. Например,
связанными списками и деревьями проще манипулировать, используя именно кучи, а не виртуальную
память (глава 15) или файлы, проецируемые в память (глава 17) Преимущество динамически
распределяемой памяти в том, что она позволяет Вам игнорировать гранулярность выделения памяти
и размер страниц и сосредоточиться непосредственно на своей задаче. А недостаток — выделение и
освобождение блоков памяти проходит медленнее, чем при использовании других механизмов, и,
кроме того, Вы теряете прямой контроль над передачей физической памяти и ее возвратом системе. "
Из Рихтера
скорее всего в этом дело, наверно, ОС не торопиться забираь у процесса опер-ую память, а то вдруг вскоре он опять у неё её попросит а тут хоп на те сразу...
← →
Тимохов © (2004-05-10 13:06) [48]
> default © (10.05.04 13:03) [47]
Если я не ошибаюсь кучи не имеют отношения к дельфовому менеджеру памяти.
Весь ответ в копании ссылки http://rsdn.ru/article/Delphi/memmanager.xml
Дома посмотрю...
← →
default © (2004-05-10 13:27) [49]Тимохов © (10.05.04 13:06) [48]
да, по этому менеджер и основан на ф-их выдел-ия вирт-ой памяти поскольку там сам контр-ешь когда память получаешь когда отдаёшь, в кучах же дейс-ют свои алгоритмы...
но на мой взгляд уже не важно всё это не освоб-ет мен-ер памяти её же сразу и всё тут, а почему уже и не так важно, написав свой
мен-ер памяти мы сможем со 100% вер-ью определять битость ссылки на объект, но мне это не больно интересно, понимаю этот новый алгоритм управления памятью работал бы для всей системы, а то только в Delphi...
← →
Игорь Шевченко © (2004-05-10 13:42) [50]Sergey Masloff (10.05.04 10:58)
LOL
Страницы: 1 2 вся ветка
Форум: "Потрепаться";
Текущий архив: 2004.05.30;
Скачать: [xml.tar.bz2];
Память: 0.54 MB
Время: 0.032 c