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
<fpc-devel@lists.freepascal.org> 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.
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
