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

Michael Van Canneyt michael at freepascal.org
Mon Apr 30 14:59:25 CEST 2018



On Mon, 30 Apr 2018, Maciej Izak wrote:

> 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.

Maybe because your solution is simply not convincing and I wish to try and
find a solution just a little harder ?

Allow me to exaggerate the point a little:

A bunch of changes are introduced, things are rammed through our throat 
which we didn't ask for and then we're told "this is the price for progress'.

It should come as no surprise that questions are asked, in such a situation.

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

The point is that when you use the other features, you know and accept the
consequences. I only use strings & dynamic arrays as managed types. 
The benefits are clear, so I accept the management overhead they incur. 
I don't use interfaces (except Corba interfaces, no overhead there).

So I can perfectly estimate the impact of managed types on my code.

This is different: I don't want/need this feature, but I am hit by the
overhead anyway, if I understand you correctly. I cannot avoid it.

So yes, I definitely think that this question needs to be asked again.

Note that I am not asking you to revert the situation, but I would like to
see a little more effort to ensure the impact on people that do not use a
feature, is as small as technically possible.

Maybe other people can contribute to a solution that satisfies everyone.

Michael.



More information about the fpc-devel mailing list