Что происходит с объектом, который падает из области в Delphi?

Question

Когда объект, созданный внутри функции и функции, завершен, что происходит с объектом, если он не был явно уничтожен?

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

Так, например, что происходит с locallist после того, как custom_function был вызван?

function TForm1.custom_function(string: test_string): boolean; 
var locallist: TStringList; 
begin 
    locallist := TStringList.Create; 
    // do a bunch of stuff here, but don't destroy locallist 
    return true; 
end; 

Answer 1

вы получите утечку памяти.

Правильная картина

myObject := TObject.Create; 
try 
    //do stuff 
finally 
    myObject.Free; 
end; 

Кроме того, если вам необходимо проверить позже, если объект был освобожден, а затем использовать FreeAndNil (MyObject). Он также установит переменную в нуль, чтобы вы могли ее протестировать позже.

Answer 2

Это утечка памяти.

Вы должны, как правило, окружают такие распределения, таким образом:

locallist := TStringList.Create; 
try 
    // work with locallist here 
    finally 
    locallist.Free; 
    end; 

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

Answer 3

Память не восстановлена, извините. Вы должны явно освободить этот объект, используя locallist.Free;

Answer 4

Это приведет к ошибке memory leak, которая будет уничтожена только в конце приложения. Чтобы обнаружить их, вы можете использовать диспетчер памяти, например FastMM.

Обратите внимание, что вы можете уничтожать объекты с помощью метода Destroy или Free. Первым выдаст ошибку, если объект равен нулю, то последняя не будет - она ​​равна

if Assigned(Object) then Object.Destroy; 

Answer 5

Как отмечали другие плакаты, эти объекты должны быть явно освобождены. Обычно это делается вручную с помощью блока try..finally, как показал Рэй. Однако есть исключения, о которых вы должны знать.

Компоненты (потомки TComponent) передают свой конструктор своему конструктору. Если владелец не nil, тогда компонент владельца получит право собственности на новый компонент и освободит его при его освобождении. Вот почему вам не нужно очищать свои собственные формы; они подключены к объекту Application, который знает, как освободить себя, когда программа закончена. Однако, если вы создаете компонент во время выполнения, вам нужно либо присвоить его владельцу, либо передать nil конструктору, а затем бесплатно загрузить его. Не смешивайте их, освобождая компонент вместе с владельцем. Это может привести к условию двойного освобождения при определенных обстоятельствах.

Связанные объекты, которые реализуют подсчет ссылок (в основном, потоки TInterfacedObject) освобождаются механизмом подсчета ссылок, если вы ссылаетесь на них конкретно как на интерфейс (а не как на объект). Они автоматически освобождаются, когда последняя ссылка на них удален. Не освобождайте объект TInterfacedObject вручную, если вы уже присвоили ему ссылку на интерфейс. Это вызовет исключение.Кроме того, имейте в виду, что не все объекты с интерфейсами реализуют подсчет ссылок. В основном только те, которые происходят от TInterfacedObject.

Не всегда удобно создавать объект, использовать блок try..finally, а затем освобождать его. Иногда это просто не работает для того, что вы делаете, особенно если вы назначаете объект в какой-то список (и делаете их очень много). В этом случае рекомендуется использовать TObjectList (или еще лучше, если у вас есть D2009, TObjectList) с свойством OwnsObjects, установленным на true. Это приводит к тому, что список становится владельцем объектов в нем и освобождает их, когда он освобождается, как и компоненты. Опять же, не освобождайте объект вручную, если он принадлежит списку объектов.

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

Это, вероятно, звучит сложно, но вы скоро привыкнете к нему. Просто помните, что каждый объект принадлежит одной из трех вещей: другому объекту, системе подсчета ссылок на интерфейс или вашему коду, а владелец должен освобождать все свои объекты, когда они больше не нужны. Ничто не должно пытаться освободить то, что принадлежит другому. (Нельзя красть.) Помните эти рекомендации, и вы получите хорошее управление памятью. Вы также можете установить «ReportMemoryLeaksOnShutdown: = true» в основной процедуре вашего DPR для получения дополнительной помощи.