[fpc-devel] Defer keyword

[Benito van der Zander]

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 at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20210507/aca84763/attachment.htm>