FreeAndNil

← →
Anatoly Podgoretsky © (2007-09-22 14:36) [40]

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

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

← →
oxffff © (2007-09-22 14:44) [41]

> Anatoly Podgoretsky © (22.09.07 14:36) [40]
> > oxffff (22.09.2007 14:32:39) [39]
>
> Может из-за var
> В этом случае да, параметры не идентичны.

Так является ли это упущением с вашей точки зрения?

Ведь именно по этой причине FreeAndNil имеет вид

procedure FreeAndNil(var Obj);

а не

procedure FreeAndNil(var Obj:Tobject);

Почему если типы совместимы, ссылки на них не совместимы?

Повторю еще раз

Так является ли это упущением с вашей точки зрения?

← →
Anatoly Podgoretsky © (2007-09-22 14:50) [42]

> oxffff (22.09.2007 14:44:41) [41]

Мне как то все равно до FreeAndNil я ее не использую.

← →
oxffff © (2007-09-22 14:54) [43]

Еще из этого разряда. Почему компилятор не пропускает

procedure abc(p:ppointer);
begin
end;

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

Incompatible types: "TObject" and "Pointer"

IMHO.
Компилятор слегка подстроить для нормальной обработки этой ситуации.
А именно, если типы совместимы, то и ссылки и указатели на них должны совместимы
IMHO.

← →
Anatoly Podgoretsky © (2007-09-22 14:57) [44]

> oxffff (22.09.2007 14:54:43) [43]

Ну так и говорит - типы не совместимые.

← →
oxffff © (2007-09-22 15:00) [45]

> Anatoly Podgoretsky © (22.09.07 14:57) [44]
> > oxffff (22.09.2007 14:54:43) [43]
>
> Ну так и говорит - типы не совместимые.

Ну а почему вы можете присвоить Tobject к pointer. И наоборот.

Почему?

← →
Leonid Troyanovsky © (2007-09-22 15:00) [46]

> oxffff © (22.09.07 14:54) [43]

> Еще из этого разряда. Почему компилятор не пропускает

Конечно, достаточно уйти от var и никаких ограничений,
за исключением необходимости добавлять @.
type PObject = ^TObject; TMyObject = class x: TObject; end; procedure abc(a: PObject); begin ShowMessage(a^.ClassName); a^ := nil; end; procedure TForm1.Button1Click(Sender: TObject); var a:tMyobject; begin a:= TMyobject.Create; a.x := TObject.Create; abc(@a.x); Caption := Format("%p", [Pointer(a.x)]); end;

Только, подобная "гибкость" только плодит проблемы.

--
Regards, LVT.

← →
oxffff © (2007-09-22 15:02) [47]

Если следовать логике компилятора.

Он должен не пропустить. Однако вы знаете он пропустит.

procedure abc(p:pointer);
begin
end;

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

← →
oxffff © (2007-09-22 15:07) [48]

> Только, подобная "гибкость" только плодит проблемы.

В чем проблема в вашем примере?

← →
Leonid Troyanovsky © (2007-09-22 15:13) [49]

> oxffff © (22.09.07 15:02) [47]

> Он должен не пропустить. Однако вы знаете он пропустит.

Ограничение относится только к var параметрам,
Types of actual and formal var parameters must be identical (E2033)

For a variable parameter, the actual argument must be of the exact type of the formal parameter.

Почитай статью.

Не пойму в чем смущение ума :)

--
Regards, LVT.

← →
Leonid Troyanovsky © (2007-09-22 15:16) [50]

> oxffff © (22.09.07 15:07) [48]

> В чем проблема в вашем примере?

В моем их нет, но в подобных - отсутствие возможности контролировать типы, т.е. та самая совместимость TObject - pointer.

--
Regards, LVT.

← →
oxffff © (2007-09-22 15:19) [51]

> Types of actual and formal var parameters must be identical
> (E2033)

> exact type

Да но к каким потенциальным граблям могут, если мы попросим их расширить эту функциональность. Вопрос в этом.

Вернемся к простому примеру с Tconrol и Tobject.

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

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

Почему бы не пропускать данный вызов. Ведь Tobject является подмножеством tControl и поэтому совместим.

Почему авторы ограничили именно до exact type?

← →
oxffff © (2007-09-22 15:22) [52]

> Leonid Troyanovsky © (22.09.07 15:16) [50]
>
> > oxffff © (22.09.07 15:07) [48]
>
> > В чем проблема в вашем примере?
>
> В моем их нет, но в подобных - отсутствие возможности контролировать
> типы, т.е. та самая совместимость TObject - pointer.

Но тем не менее проблем будет имхо не больше, чем когда вы пишите так

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

← →
Ping (2007-09-22 15:28) [53]

Почему бы не пропускать данный вызов. Ведь Tobject является подмножеством tControl и поэтому совместим.

procedure Test(var Obj: TObject); begin Obj := TBitmap.Create; end; procedure TForm1.Button1Click(Sender: TObject); var Obj: TWinControl; begin Test(Obj); end;

Вот поэтому...

← →
oxffff © (2007-09-22 15:34) [54]

> Вот поэтому...

Но Imho это решаемо.
Захочешь ограничить. Сделаешь так

procedure Test(var Obj: TControl);
begin
Obj := TBitmap.Create;
end;

← →
Ping (2007-09-22 15:37) [55]

Захочешь ограничить. Сделаешь так

Как это относится к FreeAndNil()?

← →
oxffff © (2007-09-22 15:41) [56]

> Как это относится к FreeAndNil()?

oxffff © (22.09.07 14:44) [41]

← →
Leonid Troyanovsky © (2007-09-22 15:46) [57]

> oxffff © (22.09.07 15:22) [52]

> Но тем не менее проблем будет имхо не больше, чем когда
> вы пишите так

Ну, это, скорее, вынужденые локальные меры.
Информация о типе, видимо, сохраняется "в уме" пишущего.
А от глобальных процедур требуют большего.
Т.е., чтобы случайно не передать туда не то.

--
Regards, LVT.

← →
Ping (2007-09-22 15:52) [58]

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

Но

При передаче параметров по ссылке (var), при предлагаемом тобой подходе, можно вернуть все, что душе угодно (в пределах наследования). Компилятор - он не телепат. Есть формальная логика. И если для Паскаля постулируется сильная типизация, то компилятор, при передаче по ссылке, будет требовать, чтобы передаваемая ссылка была на объект требуемого типа. Не нравится - пиши на С.

P.S. "Я дерусь... потому что я... дерусь!" (С) ?

← →
oxffff © (2007-09-22 15:59) [59]

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

Сильная типизация?
А как насчет в совместимости pointer и Tobject?
Далее как насчет дочерних типов?

>P.S. "Я дерусь... потому что я... дерусь!" (С) ?

Я хочу сделать свою жизнь проще. :)

← →
Anatoly Podgoretsky © (2007-09-22 16:18) [60]

> oxffff (22.09.2007 15:59:59) [59]

Pointer и pPointer разные вещи, вторая уже строгая типизация

← →
oxffff © (2007-09-22 16:29) [61]

> Anatoly Podgoretsky © (22.09.07 16:18) [60]
> > oxffff (22.09.2007 15:59:59) [59]
>
> Pointer и pPointer разные вещи, вторая уже строгая типизация

А почему язык со строгой типазацией закрывает глаза на первую?
И причину такого поведения не подскажите?

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

← →
Anatoly Podgoretsky © (2007-09-22 16:34) [62]

То что это документировано, или передаешь var Name без типа или var Name: тип, тогда должно быть соответствие формальных и фактических параметров.

← →
Anatoly Podgoretsky © (2007-09-22 16:35) [63]

А насчет хотелок, многие хотели бы превратить Паскаль в Си или Бейсик и обидно, что Борланд иногда идет на поводу.

← →
oxffff © (2007-09-22 16:39) [64]

> Anatoly Podgoretsky © (22.09.07 16:34) [62]
> То что это документировано, или передаешь var Name без типа
> или var Name: тип, тогда должно быть соответствие формальных
> и фактических параметров.

Да об этом и речи нет.

Я о расширении языка.
И чтобы не было каламбура по типу oxffff © (22.09.07 14:54) [43].

Только скажите как в языке со строгой типизацией присутствуют конструкции untyped var, out, const педачи параметров?

← →
Anatoly Podgoretsky © (2007-09-22 16:41) [65]

> oxffff (22.09.2007 16:39:04) [64]

К Вирту, он папа и к извращенцам из Борланда.

← →
oxffff © (2007-09-22 16:45) [66]

> Anatoly Podgoretsky © (22.09.07 16:35) [63]
> А насчет хотелок, многие хотели бы превратить Паскаль в
> Си или Бейсик и обидно, что Борланд иногда идет на поводу.
>

Я все таки думую нужно быть не гордым, а расчетливым и "видеть" как одни конструкции удобнее, или быстрее других. Согласитесь, что конструкция for in действительна удобна. Хоть я и пишу до сих пор на 7 версии.Но считаю ее удобной. Также как и внесение статических методов в record.
Также как и nested types, class var. И даже те же Class helpers и record helper.
Не смотря на что приходится писать и на других языках включая С++,C#, ASM и ряд других.
Все равно Delphi мне ближе.

← →
oxffff © (2007-09-22 16:50) [67]

> Но считаю ее удобной.

Я о новых конструкциях.

Сейчас я поехал в баню париться. :)
Вечером приеду и с вашего позволения я был бы рад продолжить дисскусию.
Спасибо всем за диалог.

← →
Leonid Troyanovsky © (2007-09-22 16:55) [68]

> oxffff © (22.09.07 16:29) [61]

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

А зачем?
Передача var TObject - извращение, FreeAndNil тому иллюстрация.

Все, что нужно потомку TObject должно быть в _его_ методах,
а не в глобальных регулярных процедурах.

--
Regards, LVT.

> Все, что нужно потомку TObject должно быть в _его_ методах,
>
> а не в глобальных регулярных процедурах.

Согласитесь, что переменная типа Tobject является лишь ссылкой на объект. А методы "должны" выполнять операции связанные с объектом, а не со ссылкой на него. Поэтому технически невозможно "грамотно" обнулить ссылку на объект, по причине того, что self передается by value.
А передовать ссылку на объект by ref в метод объекта не "грамотно".
Конечно можно создать невиртуальный классовый метод в Tobject, который принимает ссылку на объект и делает то, что делает FreeAndNil.
Но фактически классовый метод является регулярной функцией с ограниченным scope и дополнительным параметром на VMT, что избыточно по причине того, что VMT является ненужным параметром, и его мы может при желании изъвлечь из объекта.

Таким образом из-за ref семантики объектов в delphi операции над ссылкой и вынесли за пределы object scope. Поэтому это не извращение.

Вопрос, а как вы бы постулили в C++, где object is value type semantic?

> конструкция for in действительна удобна. Хоть я и пишу до
> сих пор на 7 версии.Но считаю ее удобной.

Вот потому и считаешь, а я получал internal error из-за неё. Поэтому не использую&#133

> Kolan © (24.09.07 10:11) [70]
> > конструкция for in действительна удобна. Хоть я и пишу
> до
> > сих пор на 7 версии.Но считаю ее удобной.
>
> Вот потому и считаешь, а я получал internal error из-за
> неё. Поэтому не использую…

oxffff © (22.09.07 16:50) [67]

Более того я выявил баг в реализации for in и отправил на qc, который получил уже open статус

Но тем не менее cчитаю ее удобной.

> Но тем не менее cчитаю ее удобной.

Если бы переменную не заводить, то былобы хорошо совсем&#133

> oxffff © (24.09.07 10:09) [69]

> Согласитесь, что переменная типа Tobject является лишь
> ссылкой на объект. А методы "должны" выполнять операции
> связанные с объектом, а не со ссылкой на него. Поэтому технически
> невозможно "грамотно" обнулить ссылку на объект, по причине
> того, что self передается by value.

Ссылка на объект отличается от самого объекта (тоже ссылки)
лишь (лишним) разыменованием. By-reference vs by-value - тоже.

Ну, а раз оно лишнее, то это и есть изврат :)

Да и, во-ще, тема, IMHO, себя исчерпала,
а FreeAndNil - MD.

--
Regards, LVT.

"Каждому овощу своё время"...

> Leonid Troyanovsky © (24.09.07 11:29) [74]
>
> > oxffff © (24.09.07 10:09) [69]
>
> > Согласитесь, что переменная типа Tobject является лишь
>
> > ссылкой на объект. А методы "должны" выполнять операции
>
> > связанные с объектом, а не со ссылкой на него. Поэтому
> технически
> > невозможно "грамотно" обнулить ссылку на объект, по причине
>
> > того, что self передается by value.
>
> Ссылка на объект отличается от самого объекта (тоже ссылки)
> лишь (лишним) разыменованием. By-reference vs by-value -
> тоже.
>
> Ну, а раз оно лишнее, то это и есть изврат :)
>
> Да и, во-ще, тема, IMHO, себя исчерпала,
> а FreeAndNil - MD.
>
> --
> Regards, LVT.

Я думаю мы с вами говорим о разных вещах.

> Ссылка на объект отличается от самого объекта (тоже ссылки)
> лишь (лишним) разыменованием. By-reference vs by-value -
> тоже.

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

А вы как предлагаете?

procedure Tobject.FreeAndNil(var obj:Tobject);?
или class procedure Tobject.FreeAndNil(var obj:Tobject); ?

> oxffff (24.09.2007 12:12:17) [77]

Tobject.Free;
Tobject := nil;

И не будет таких фокусов, как

FreeAndNil(Integer)

> FreeAndNil(Integer)

freeandnil(integer);
freeandnil(5);

Такое даже не откомпилируется. ;)

Тогда уж типизировать параметр.

Borland же честно подписал "Be careful to only pass TObjects to this routine." :)

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