> 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 system. >> 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 classes. > > 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: var someClass: TMyObject; retained someClass: TMyObject; begin end; {$RETAINED+} type TMyObject = class private someClass: TMyObject; public retained someClass: TMyObject; otherClass: TObject; // this would give an error because class is not compiled for ARC end; {$RETAINED-} Regards, Ryan Joseph _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel