[fpc-devel]Proposal for audo-destructors

[Nico Aragón]

Hello,

On Sun, 12 Sep 2004 15:28:40 +0200 (CEST), Michael.VanCanneyt at Wisa.be
wrote:

>> >   procedure CopyFile(SourceFileName, TargetFileName: string);
>> >   auto
>> >       s, t: TStream;
>> >   begin
>> >       s := TFileStream.Create(SourceFileName, fmOpenRead);
>> >       t := TFileStream.Create(TargetFileName, fmCreate);
>> >       t.CopyFrom(s);
>> >   end;
>
>It is not so easy. What about the following code:
>
>   procedure CreateIOStream(Var AStream : TStream);
>   auto
>      t: TStream;
>   begin
>      s := TFileStream.Create(SourceFileName, fmOpenRead);
>      // Something
>      AStream:=S;
>   end;

This code is wrong. If you use "auto", your goal is to schedule the
variable for destruction when the current function is left. If you
want the variable to survive outside, then you should declare it as
normal "var".

The question would be how should the compiler react to this error. I
think that issuing a warning would be a sensible choice, because it's
sort of symmetrical to "variable 'foo' might not have been
initialized".

Borland way, since the first versions of TP has been to allow
programmers to shoot theirselves in the foot... if they're really
decided to do so and explicitily state it. 

>Here the assignment is explicit, but it could be implicit as well.

A direct assignment (to global variable or output parameter) would be
easy to detect and warn the programmer. If you use "Move" or something
like that, then you're badly begging to shoot yourself in the foot :-)

I can only think of a case, that's really difficult (not impossible)
to track: a local variable that is assigned to a global one by means
of a call to a function. 

>It's not possible to solve this kind of issue without some form 
>of reference counting.

Reference counting is more complex. You have written the
implementation for ansistring anyway. It would be nice to have it
extended to objects too.

>The matter has been discussed several times by the FPC core group, at great
>length. No satisfying solution on which everyone agreed was reached. 

I would really appreciate some comments on my question about patches
that would implement "optional", "unofficial" or "pluggable" features.
I would like very much to be able to build extensions for particular
idioms. I understand that not everybody will like this possibility.
The question is if core developers would dislike it so much as to
prefer to keep it off the official code.

It's also possible to implement extensions using some kind of
preprocessor. But then a lot of code would be duplicated because the
preprocessor must do a considerably more complex job than macro
substitution... much like what the compiler itself does later.

I'm not asking just out of curiosity. I have some ideas and code and
would like to know if/how could fit with FPC.



--
saludos,
  
  Nico Aragón

NOTE: na-list address only works for messages coming from lists.
Please, write to "nico" at the same domain for direct email.