Hi,
Don't forget that the record/management operator approach will again
blow up binary size; for every variable declared like this you risk
creating a new type.
the classic Delphi way was to use an interface for freeing. It only
requires one type and nothing blows up.
type
TDefer = class(TInterfacedObject)
toDefer: TObject;
constructor Create(anobject: tobject);
destructor destroy; override;
end;
constructor TDefer.Create(anobject: tobject);
begin
toDefer := anobject;
end;
destructor TDefer.destroy;
begin
toDefer.free;
inherited destroy;
end;
function deferedFree(obj: TObject): IUnknown;
begin
result := TDefer.Create(obj);
end;
Then it can be used as:
procedure test;
var
sl: TStringList;
begin
sl := TStringList.Create;
deferedFree(sl);
writeln(sl.count);
end;
Unfortunately it fails in FreePascal because the interface is released
too soon.
At worst, one could use a temporary variable in Delphi:
procedure test;
var
sl: TStringList;
begin
sl := TStringList.Create;
var temp := deferedFree(sl);
writeln(sl.count);
end;
The introduction of generics and their abundant use in Delphi has
noticably slowed down the compiler and increased binary sizes. To my
dismay, compile times of 20 seconds up to 2 minutes have become not
uncommon in Delphi. Something almmost unthinkable in D7 days.
With these generics they copied all the problems of C++. One of the
worst ways of doing that
It would have been better to implement them like dynamic arrays. The
generic code gets RTTI, the specialization does not generate any code,
and just avoids explicit casting.
Cheers,
Benito
On 07.05.21 11:08, Michael Van Canneyt via fpc-devel wrote:
On Fri, 7 May 2021, Sven Barth via fpc-devel wrote:
I thought it was agreed at the time that this was the most viable way
forward ?
As far as I remember there wasn't really any agreement.
Can be, I was not sure... I remember this path was investigated.
IIRC there was also the proposal that this could be done automatically
using
a keyword:
var
SomeClass : TSomeClass; dispose;
The compiler can internally create the management record with a single
default
field and the needed management operator, so the user does not need
to create all that.
I'm not aboard with such a keyword. The compiler should provide the
necessary language mechanisms (default field, operator hoisting) and
then
there should be a default implementation as part of the RTL. There is no
need to hide this behind a keyword, attribute or whatever.
There is:
Using a keyword, the compiler could also optimize things by simply
initializing and freeing the instance if the usage of the object in
the procedure allows it; it would allow to skip the record and
operators and whatnot.
I'm not proposing to abolish the record approach, just an additional
automatism that will use it, but allows to skip it for simple enough
cases which are
probably the largest use-case.
Don't forget that the record/management operator approach will again
blow up binary size; for every variable declared like this you risk
creating a new type.
The introduction of generics and their abundant use in Delphi has
noticably slowed down the compiler and increased binary sizes. To my
dismay, compile times of 20 seconds up to 2 minutes have become not
uncommon in Delphi. Something almmost unthinkable in D7 days.
If that can be avoided by use of a keyword for 90% of use cases, I
think it is worth thinking about it and not dismissing it offhand.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
