FreeAndNil против Free. Интересная концепция.

← →
Игорь Шевченко © (2009-06-03 10:56) [120]

Юрий Зотов © (03.06.09 04:18) [119]

> Угу, совсем мимо. В унаследованном обработчике возникает
> исключение - и переменная не обнуляется. После чего вся
> логика летит совсем мимо. С непредсказуемыми результатами.
>

А с чего ему возникать ?

← →
Юрий Зотов © (2009-06-03 11:32) [121]

> Игорь Шевченко © (03.06.09 10:56) [120]

С того, что [19]. Надо ведь быть последовательным в своих высказываниях, не так ли?

← →
Игорь Шевченко © (2009-06-03 12:08) [122]

Юрий Зотов © (03.06.09 11:32) [121]

А я, собственно, вполне последователен. [19] относится к деструктору, спорный фрагмент - к событию формы. Почувствуйте разницу

← →
Юрий Зотов © (2009-06-03 12:26) [123]

> Игорь Шевченко © (03.06.09 12:08) [122]

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

Почувствуйте разницу.

← →
Игорь Шевченко © (2009-06-03 12:46) [124]

Юрий Зотов © (03.06.09 12:26) [123]

Юра, я тебе могу сказать еще раз - криворукий программист испортит программу таким способом (и не единственным, причем), против которого любая защита будет бессильна.

Есть предложение завершить дискуссию.

← →
Юрий Зотов © (2009-06-03 13:39) [125]

> Игорь Шевченко © (03.06.09 12:46) [124]

То есть, нет никакого смысла закрывать криворукому программисту возможность нарушить работу программы. В таком случае надо быть последовательным: все члены всех классов помещаем в public, все методы делаем виртуальными, все объявления выносим в interface - пущай себе резвится.

Предложение принимается.

← →
Игорь Шевченко © (2009-06-03 13:40) [126]

> В таком случае надо быть последовательным: все члены всех
> классов помещаем в public, все методы делаем виртуальными,
> все объявления выносим в interface - пущай себе резвится.
>

Дурное дело нехитрое

← →
Дмитрий Белькевич (2009-06-04 12:00) [127]

Итак... Очередной баг с помощью FreeAndNil откопал. Что характерно, с локально созданным и разрушенным объектом. Рассказываю.

Использую компоненты TBX. Для их редактирования использую модуль TBXEdit.

Вызываю его так:

TBXSetUpEditForm([TBXToolbar1, TBXToolbar3], [], [TBXItem126], fRegistryKey, 0, True, True, False, False, {nil,} PngImageList1); ToolbarEditForm := TToolbarEditForm.Create(Self); try ToolbarEditForm.ShowModal; finally FreeAndNil(ToolbarEditForm); end;

После изменения на FreeAndNil появилось AV при закрытии формы. Смотрим почему.

ToolbarEditForm - это глобальная переменная юнита TBXEdit:

var
ToolbarEditForm: TToolbarEditForm;

В юните есть такой код:

procedure DisableEdits; begin with ToolbarEditForm do begin eCaption.Enabled := false; ...... //Checkbox1.Enabled := false; end; end;

Этот код вызывается после разрушения формы. Как я понял, какое-то событие остаётся необработанным и вызывает этот код.

Таким образом мы видим:

1. Преимущество подхода тотальной (хотя бы временной) замены Free на FreeAndNil.
2. Неверно спроектированный код.
3. Недостатки использования сторонних компонент (хотя я их использую везде, где только могу).
4. Недостатки глобальных переменных.

Дмитрий Белькевич (04.06.09 12:00) [127]

> 1. Преимущество подхода тотальной (хотя бы временной) замены
> Free на FreeAndNil.

Как средство поиска ошибок - любые средства хороши. В том числе и MemProof, BoundsChecker, FastMM с включенной опцией контроля утечек.

> 2. Неверно спроектированный код.

Дальше можно не рассказывать.

> 4. Недостатки глобальных переменных.

Дай дураку член стеклянный, он и руки порежет и член разобьет

← →
Дмитрий Белькевич (2009-06-04 13:49) [129]

> Как средство поиска ошибок - любые средства хороши. В том
> числе и MemProof, BoundsChecker, FastMM с включенной опцией
> контроля утечек.

Больше инструментов - не меньше. FastMM сам постоянно использую. Иногда и FullDebugMode включаю в нём. Иногда такое вылазит %)

Для глобальных и других долгоживущих переменных обНИЛивание полезно взять за правило
Оbj.Free; Obj:=nil;
Иначе проблематично применить
if not Assigned(Obj) then obj:=TObj.Create()

FreeAndNil против Free. Интересная концепция. Найти похожие ветки