> On May 6, 2021, at 11:40 PM, Sven Barth <[email protected]> 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 - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
