> On May 6, 2021, at 11:40 PM, Sven Barth <pascaldra...@googlemail.com> wrote:
> There is no "finalization" section. It's really just an implicit try ... 
> finally block that the compiler inserts. Look for "cs_implicit_exceptions" 
> and "pi_needs_implicit_finally" if you want to learn more.

Does that mean if you disable implicit exceptions then ALL ref counted types 
leak memory? I could swear there was some post-routine code did all the cleanup 
stuff and called finalization* on different types. That's how record operators 
worked I thought and so i thought a defer keyword could simply hook into that 

>> Either way looking at the programming language landscape the better way 
>> forward seems to be some opt-in ARC for TObject but I don't know if the 
>> compiler team is receptive to that (Sven made some attempt years ago but 
>> abandoned it). it's kind of frustrating that we have ref counted types but 
>> that isn't extended to classes. Hopefully that's something we can tackle one 
>> of these days...
> The problem is that the whole class tree needs to support it for it to work 
> correctly even if it's not the whole hierarchy that has as it enabled. That 
> means at least one additional field inside TObject that a) controls that 
> behavior and b) contains the reference count. This means that *all* class 
> instances increase by a LongInt. This might not sound like much, but FPC also 
> allows to work on smaller systems (and I don't mean the really small embedded 
> ones as those don't have TObject enabled anyway) and there an additional 
> LongInt for each instance might be critical.

That can never be an option to blow up TObject. I figured there could be 
something like a $M+ switch that would compile a class with ref counting. Then 
in the RTTI units we would simply have an entry for this new class type which 
had initialize/finalize/addref etc... functions. I saw this for record 
operators and dynamic arrays so I thought the system could be extended to 

> If the reference count feature is optional (in addition to the above) then an 
> open question is what would happen if such a reference counted instance is 
> assigned to a non-reference counted one. This would need to take into account 
> all ways such an instance or type can be used including TClass.

That doesn't sound like a problem to me but I haven't thought about it deeply. 
If it was confusing there could be a new var section to denote ARC objects:

  someClass: TMyObject;
  someClass: TMyObject;

  TMyObject = class
      someClass: TMyObject;
    public retained
      someClass: TMyObject;
      otherClass:  TObject; // this would give an error because class is not 
compiled for ARC

        Ryan Joseph

fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Reply via email to