Hello, On Sun, 12 Sep 2004 15:28:40 +0200 (CEST), [EMAIL PROTECTED] 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髇 NOTE: na-list address only works for messages coming from lists. Please, write to "nico" at the same domain for direct email. _______________________________________________ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel