Am 07.05.2021 um 00:32 schrieb Ryan Joseph via fpc-devel:

On May 6, 2021, at 4:26 PM, J. Gareth Moreton via fpc-devel 
<> wrote:

There is a performance penalty when using them, which one reason why the 
compiler sources don't use them.  There's probably other reasons too.  There 
might be some speed-up potential where standard Exit calls are concerned, but 
I'm not sure.
I just did a search and I did indeed see a few try..finally blocks but not many. As I 
understand it there is a "finalization" section of each procedure which is used 
for ref counted objects so I assumed the statement was merely moved to that location but 
I guess there's some concerns over exceptions.
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.
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.

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.

If the reference count would be enabled by default for *all* instance (like Delphi did in its platform compilers but which they abandoned now) then you'd have a huge backwards compatibility problem, because there definitely are cycles out there and thus this option would be an absolute no-no.

In my opinion the better solution is to continue the road that Maciej started and to implement that "default field" concept together with operator hoistening so that records with management operators can be used as containers. This is essentially the way it's done in C++ as well (e.g. we use that extensively at work), but it needs some questions solved for the default field functionality. This way the functionality is definitely optional and can be controlled per-instance instead of per-type. What it wouldn't solve however would be the assignment problems ("wrapped" to non-"wrapped" instance) though that could be probably be more or less solved by only allowing an explicit conversion to the non-"wrapped" instance.

fpc-devel maillist  -

Reply via email to