FreeAndNil

← →
mike_zav (2007-09-21 17:37) [0]

В каких случаях применяют FreeAndNil? А в каких просто .Free?
Зачем это нужно? Если можно с примером.

← →
Ega23 © (2007-09-21 17:40) [1]

FreeAndNil(obj) применяют в тех случаях, когда впадлу написать
obj.Free;
obj:=nil;

> Зачем это нужно?

Это нужно для того, чтобы в одном случае ссылка стала равной nil, а в другом - нет.

З.Ы. Ни разу FreeAndNil не использовал.

← →
Инс © (2007-09-21 17:42) [2]

> В каких случаях применяют FreeAndNil?

Например, если в будущем понадобится проверить, уничтожен ли экземпляр, на который ссылается данная переменная/поле класса.

← →
stanislav © (2007-09-21 17:45) [3]

http://delphimaster.net/view/2-1190379982/

← →
Leonid Troyanovsky © (2007-09-21 17:48) [4]

> mike_zav (21.09.07 17:37)

> Зачем это нужно? Если можно с примером.

Да, собс-но, не нужно. Ну, может, писать короче.
Но, от неприятностей оно не спасет.

--
Regards, LVT.

← →
Anatoly Podgoretsky © (2007-09-21 18:55) [5]

> mike_zav (21.09.2007 17:37:00) [0]

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

← →
Anatoly Podgoretsky © (2007-09-21 18:56) [6]

> Инс (21.09.2007 17:42:02) [2]

Переменная это недостаток, а поля можно и нужно делать контролируемыми.

← →
mike_zav (2007-09-21 19:34) [7]

Бррр.. так я и не понял одного, это должно спасти от ложного срабатывания Assign, при уже уничтоженном объекте?

← →
Сергей М. © (2007-09-21 19:39) [8]

> mike_zav (21.09.07 19:34) [7]

> это должно спасти .. ?

А куда ему деться с подводной лодки ?)

"Согласие есть продукт при полном непротивлении сторон" (С)

FreeAndNil "нилит" переменную, а Assigned, видя этот "нил", согласен и имеет все основания выдать False.

← →
Инс © (2007-09-21 20:05) [9]

> Никогда не применял, за ненадобностью подобной функций,
> которая была сделана Борландом для забывчивых и неумеющих.
> Наличие подобной функции как правило говорит о недостатках
> в программе.

Ну, значит Borland сами забывчивы и неумеющие :) Например, в модуле Graphics - используется повсеместно. Например класс TBitmap метод GetCanvas вначале проверяет на равенство поля FCanvas nil, и только потом в случае успешной проверки создает экземпляр TCanvas. А когда Canvas становится невалидным (например, после вызова Dormant) - уничтожает ее и обнуляет ссылку. Теперь, если вдруг кто-либо обратится к свойству Canvas, снова вызывается GetCanvas, проверяется на nil и т.д.
Т.е. благодаря обнулению ссылок можно создавать вложенные объекты только по требованию.

← →
Anatoly Podgoretsky © (2007-09-21 20:11) [10]

> Инс (21.09.2007 20:05:09) [9]

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

← →
Инс © (2007-09-21 20:14) [11]

> [10] Anatoly Podgoretsky © (21.09.07 20:11)

Прошу прощения, не совсем понял вашу последнюю мысль...

← →
Anatoly Podgoretsky © (2007-09-21 20:15) [12]

> Инс (21.09.2007 20:14:11) [11]

Что именно, я же много о чем говорил.
Может термин повторное использование переменных?

← →
Инс © (2007-09-21 20:18) [13]

> FCanvas это контролируемая вещь, которую не обойдешь, а
> обнулить я предпочту явно.

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

> Может термин повторное использование переменных?

Нет, с этим как раз все понятно.

← →
Инс © (2007-09-21 20:21) [14]

А, все, кажется понял...

← →
Anatoly Podgoretsky © (2007-09-21 20:21) [15]

> Инс (21.09.2007 20:18:13) [13]

> FCanvas это контролируемая вещь, которую не обойдешь, а
> обнулить я предпочту явно.

> Несколько раз перечитал это предложение, не могу понять смысл...

Все равно не понятно, что именно непонятно.
Что такое контролируемое или почему явно?

← →
Anatoly Podgoretsky © (2007-09-21 20:23) [16]

Функция FreeAndNil сравни функии IncDay

← →
Anatoly Podgoretsky © (2007-09-21 20:24) [17]

> Инс (21.09.2007 20:21:14) [14]

Не если не понял не стесняйся уточнить.

← →
Инс © (2007-09-21 20:25) [18]

Комментирую [10]:

> только на пользовательском уровне

Ну, мы же вроде не только пользователи, но и программисты, иногда классы приходится писать самому. А следовательно может возникнуть подобная ситуация. И тогда можно действовать подобным образом. У меня даже когда-то было что-то похожее, но вот пока найти не могу, привел бы пример. А значит слишком категоричное утверждение о забывчивости и неумении становится не совсем верным. Случаи ведь разные бывают.

← →
Anatoly Podgoretsky © (2007-09-21 20:35) [19]

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

> public > X: type;

и

private FX: type; published X: type read FX write FX;

большая и тем более для

private FX: type; function GetX: type; procedure SetX(X: type); published X: type read FX write FX;

Практически весь VCL пропитан этим.
И в третьем случае полный контроль над членом класса, без утечек и непридвиденного измения.

X := TBitmap.Create; X := TBitmap.Create; X := TBitmap.Create; X := TBitmap.Create; X := nil;

Никаких утечек, несмотря что нет разрушения старого значения.

← →
Anatoly Podgoretsky © (2007-09-21 20:36) [20]

Очепятка в третьем примере

published
X: type read GetX write SetX;

← →
Инс © (2007-09-21 20:41) [21]

> Очепятка в третьем примере

Я догадался, все в порядке :)

Как считаете, в данной дискусии был раскрыт вопрос автора или нет? Истина найдена? Итоги подводить можно?

← →
Anatoly Podgoretsky © (2007-09-21 20:44) [22]

> Инс (21.09.2007 20:41:21) [21]

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

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

← →
Инс © (2007-09-21 20:52) [23]

Ясно, пациент безнадежен :) Ладно, дальше спорить не буду. Вот это разве что прокомментирую.

> Функция была изобретена для ленивых и она не обязательна к
> использованию, более того она провоцирует на не совсем безопасный код

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

← →
Anatoly Podgoretsky © (2007-09-21 21:03) [24]

> Инс (21.09.2007 20:52:23) [23]

Не будем рассматривать особые случае, я оперирую более общей сущностью.

← →
Инс © (2007-09-21 21:09) [25]

> Не будем рассматривать особые случае, я оперирую более общей
> сущностью.

Я спорю только с категоричностью утверждения. Говорю, что в таком виде вывод не верный, есть оговорки. Вот и пытаюсь их обговорить...

← →
Anatoly Podgoretsky © (2007-09-21 21:12) [26]

> Инс (21.09.2007 21:09:25) [25]

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

← →
Инс © (2007-09-21 23:10) [27]

И снова возвращаясь к первоначальной постановке вопроса... Мне тут статейку одну по этой теме подсказали (спасибо DRON ;-) ), немного трудновато написано, но все равно рекомендую:
http://blogs.codegear.com/abauer/2006/11/01/28852

← →
Anatoly Podgoretsky © (2007-09-22 11:56) [28]

> Инс (21.09.2007 23:10:27) [27]

Полемика NilAndFree или FreeAndNil ведется с момента появления функции.
Так же как и необходимость в данной функции.
Все остаются при своих.

> Anatoly Podgoretsky © (22.09.07 11:56) [28]
> > Инс (21.09.2007 23:10:27) [27]
>
> Полемика NilAndFree или FreeAndNil ведется с момента появления
> функции.
> Так же как и необходимость в данной функции.
> Все остаются при своих.

А спор о чем?

> oxffff (22.09.2007 13:22:29) [29]

Спор ведется о буквах, мол неправильное название и спор ведется уже не один год.

> Anatoly Podgoretsky © (22.09.07 13:31) [30]
> > oxffff (22.09.2007 13:22:29) [29]
>
> Спор ведется о буквах, мол неправильное название и спор
> ведется уже не один год.

Дык и текущая реализация не идеальна.

Ловим AV.
:)

procedure TForm1.Button1Click(Sender: TObject);
var a:^TObject;
begin
a:=nil;
Freeandnil(a^);
end;

> oxffff (22.09.2007 13:34:31) [31]

Реализаций по сути две
FreeAndNil и NilAndFree

Реализация функции мне не нравится по следующей причине

procedure FreeAndNil(var Obj);

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

procedure FreeAndNil(var Obj: TObject);

То таких бы претензий у меня не было. Компилятор бы просто не пропустил многие ошибки.

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

> Anatoly Podgoretsky © (22.09.07 13:44) [32]
> > oxffff (22.09.2007 13:34:31) [31]
>
> Реализаций по сути две
> FreeAndNil и NilAndFree
>
> Реализация функции мне не нравится по следующей причине
>
> procedure FreeAndNil(var Obj);
>
> Видим уход от типизации и соответсвенно невозможность проверить
> еще на этапе компиляции.
> Почему они так поступили конечно понятно, но я бы их расстрелял.
>
> Вот если бы они реализовали так
>
> procedure FreeAndNil(var Obj: TObject);
>
> То таких бы претензий у меня не было. Компилятор бы просто
> не пропустил многие ошибки.

А мне собственно не понятно почему они поставили untyped параметр?

> oxffff (22.09.2007 13:51:34) [34]

> А мне собственно не понятно почему они поставили untyped параметр?

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

> Anatoly Podgoretsky © (22.09.07 13:58) [35]
> > oxffff (22.09.2007 13:51:34) [34]
>
> > А мне собственно не понятно почему они поставили untyped
> параметр?
>
> Посмотри исходные коды, может станет понятно.
> Но с тезисом, что это бардак и некомпетентность ты в принципе
> согласен?

С тезисом я согласен.
Действительно FreeAndNil(var Obj: TObject) более строгое определение.

Понял ваш намек. Чтобы не мучиться с приведение var параметров.

Тогда. Вопрос.

Почему бы не добавить поддержку неявного приведения var параметров.

Если Tobject и pointer "совместимы"
Если потомок и родитель "совместимы"

Почему тогда ссылка(var параметр) на эти типы не совместимы.

Например мы же можем спокойно присваивать потомков Tobject к pointer и наоборот. Почему не сделать такое неявное приведение для var параметров.
Сейчас в голову не приходит каких либо проблем с этим. IMHO.

Почему выходит
Types of actual and formal var parameters must be identical?

Для

procedure abc(var a:Tobject);
begin
end;

procedure TForm1.Button1Click(Sender: TObject);
var a:tControl;
begin
abc(a);
end;

К каким проблемам это может привести?

> oxffff (22.09.2007 14:21:37) [37]

В данном случае ни к каким, поскольку tControl наследник от Tobject и обладает всеми его методами и полями. Вот наоборот нельзя.

> Anatoly Podgoretsky © (22.09.07 14:27) [38]
> > oxffff (22.09.2007 14:21:37) [37]
>
> В данном случае ни к каким, поскольку tControl наследник
> от Tobject и обладает всеми его методами и полями. Вот наоборот
> нельзя.

И я о том же. Только почему компилятор не пропускает это?

В чем причина этого ограничения.

Пойдем дальше. Почему ругается?

procedure abc(var a:Tobject);
begin
end;

procedure TForm1.Button1Click(Sender: TObject);
var a:pointer;
begin
abc(a);
end;

Tobject и pointer "совместимы". А передача как var параметра накладывает самые строгие ограничения.

Не считаете ли вы это упущением?

> oxffff (22.09.2007 14:32:39) [39]

Может из-за var
В этом случае да, параметры не идентичны.

FreeAndNil Найти похожие ветки