[fpc-devel] What's the status of Maciej's Smart Pointer enhancements?

Maciej Izak hnb.code at gmail.com
Mon Apr 30 14:43:02 CEST 2018

2018-04-30 13:53 GMT+02:00 Michael Van Canneyt <michael at freepascal.org>:
> You mean that a constructor call for a program that does not uses
> pointers/management operators also gets slower ?
> Can we solve this _without_ additional tricks ?
> Because the fact that a feature you do not use slows down your code is not
> really acceptable in my opinion.

It was discussed some time ago on core so I have no idea why you are asking
for this again. The "slower" is too strong word. RTL must to call internal
int_initialize in TObject.InitInstance and this is required for management
operators. The similar operation was always executed for destructors in
TObject.CleanupInstance: "int_finalize" even without new feature
"management operator" for all managed types.

With FastRTTI additional call to int_initialize is omitted when
possible. Furthermore
with FastRTTI all code is executed faster (much faster than in 3.0.x)
because all info about managed fields (for classes, objects and records) is
aggregated in single array for faster initialization/finalization. By
managed fields I mean all managed types (strings, interfaces, etc.)

So: no we can't solve this without FastRTTI (or without significant part of
FastRTTI) and this is not additional trick but new feature.

This is the same for any string and interface (or any other managed type)
inside classes. Your code is already "slows down" even when you don't use
managed types for fields (even in 3.0.x or in any previous version).
Nothing new here so probably you should change your opinion.

This is the price of managed types. FastRTTI is significant step forward
for more performant and extensive usage of managed types (also for smart

Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180430/d7e9758a/attachment.html>

More information about the fpc-devel mailing list