Ich finde es zwar schon legitim, dass Delphi die Record-Felder nicht implizit initialisiert, ist ja eine Performance-Sache.
Can't agree more, i am fan of performance.
Ich finde es zwar schon legitim, dass Delphi die Record-Felder nicht implizit initialisiert, ist ja eine Performance-Sache.
Korrekt. Das aber zusätzlich anzubieten, als Option irgendwo alà "Ich weiß, es ist langsamer, aber ist auch sicherer, also mach an" wäre trotzdem nice.
Oder eben allein schon der Check als Compiler Hint oder gar Warning: "Hey, hier arbeitest Du mit nicht initialisierten Werten!", die Du dann beachten kannst oder aber im Stil von "Ich bin ein Software-Ingenieur, ich weiß, was ich tue", an der Stelle bewusst deaktivieren kannst, das wäre auch nett. Und ehrlich gesagt ist sowas inzwischen ja auch State-of-the-art.
Can't agree more, i am fan of more concrete and double checked code by the compiler and me, also with short and beautiful readable code, State-of-the-art is progress and always helpful.
Where is the problem, it is in taking the whole thing in one way, one direction, and denying other approaches, i am always was (and still) with more tools and options to work and use and realize what in my head.
Is there a way to have both without breaking backward compatibility, yes there is, but it needs open minds, sorry for the last phrase, because i already suggest similar or the same thing in other forum, and no one commented or did they, i can't remember.
Anyway, how about adding new directive or modifier for the variables in the var section and for the inline variables, something like
Code:
Procedure Test;
var
MyRec: TMyRecord; Init;
and that it, also we can have a directive to tell the compiler to
handle every record forward in this
unit to Init to default, here comes simple initialization like filling with 0 or calling TMyRecord.Init;
Another example , which i really wish we had in Pascal/Delphi:
Code:
procedure CompareAndAddList(TargetList, SrcList1, SrcList2 : TStringList);
begin
...... // irrelevant
end;
Procedure Test;
var
List1, List2, List3 :TStringList; Auto;
begin
List1.LoadFromFile....
List2.GetDataFromSomewhere....
CompareAndAddList(List1, List2, List3);
end;
No .Create, No .Free and definitely no that ugly nested try..finally, the compiler will insert the try..finally and call the constructor and destructor for each class, and we left with concrete will defined code, error free, and beautiful very beautiful and readable code, not breaking any thing.
In my opinion %99 of try..finally is just for calling Free, well some prefer here unnecessary FreeAndNil, but also doable.
are these approaches viable ? , yes they are since the compiler does in fact insert try..finally automatically for managed types, then why it can't add it for any type, on other hand for non managed types, compiler as i understand has inline variables now, so this line "var i := 0 ;", well how is that hard to
handle the variables in var sections as inline and but insert them after "begin"
So technically it is there, just need to connect the dots, it is happening with all the
VCL components, they are created and free without your code interaction, so have a public, private or protected var as TMyClass in Parent class declared as " CL: TMyClass; auto;" and the compiler will add create and free call in the parent constructor and destructor, how this is far away from using a string in that parent class ?!!
Hope someone will read this and request such thing, so Embarcadero after finishing their cosmic ships
(eg. LSP so we can live on Mars happily ever after), will have time to make some progress on the
IDE, compiler, and may be the Lnaguage in this case.
Sorry for ranting, and sorry more if this away from topic.