SmartPointer implementations, Pros's and Con's

[Rollo62 536]

Hi there,

 

I just stumbled about an interesting article here, about SmartPointer internals https://www.beginend.net/view.dws?136077

 

This leads me to the question:

Where do we stand now, after the new CustomRecords, which one would be the most favorite SP implementation ?

 

There are some candidates out there in the field:

from Spring4D, Grijjy, Marco Cantu, now Habrahabr version, and maybe hundrets more in older style, also recently discussed here in DP.

 

To be honest, I love SmartPointer from C++, but not really used them productively in Delphi yet, the way I should, only in a few side-projects,

because of the Delphi limitations, and probable instabilities,  in the past.

This might have changed now, since CustomRecords arrived, and about one year experiences with them.

 

So I would like to start the challenge:

Which SmartPointer implementation is the clear winner here,

or maybe there is no clear winner, but maybe many different implementations, needed for many different situations.

 

What are the possible Pro's and Con's of the different designs ?

 

P.S.: (My favorite would be the Spring4D version, but maybe you can convince me otherwise).

 

[pyscripter 689]

The Spring4D is the best.  If you use Spring4D stick to it.

[Stefan Glienke 2002]

The issue with the CMR implementation is that the theoretical benefit of having less overhead is eliminated by the amount of garbage the compiler produces in some scenarios.

Version 2 in the Grijjy article works like unique_ptr in C++ but without the important feature that you cannot assign one unique_ptr to another one because well its unique (this is because the ref count is inside it and not shared across multiple references) as in

Version 3 in the Grijjy article where the ref count is shared but requires a heap allocation - Version 4 does not because it uses the monitor field but that is a hack that might break if you use it on something that uses TMonitor.

 

I have done some performance tests and because the Spring4d implementation does not use a full blown object behind the interface but a handcrafted IMT the overhead is less.

[David Heffernan 2345]

1 hour ago, Stefan Glienke said:

Version 4 does not because it uses the monitor field but that is a hack that might break if you use it on something that uses TMonitor.

Does TMonitor work correctly yet?

[pyscripter 689]

1 hour ago, David Heffernan said:

Does TMonitor work correctly yet?

I think yes after the fix discussed in this thread.

[Remy Lebeau 1394]

9 hours ago, Stefan Glienke said:

Version 2 in the Grijjy article works like unique_ptr in C++ but without the important feature that you cannot assign one unique_ptr to another one because well its unique (this is because the ref count is inside it and not shared across multiple references) as in

Version 3 in the Grijjy article where the ref count is shared but requires a heap allocation

Then it acts more like C++'s std::shared_ptr than std::unique_ptr.

[Fr0sT.Brutal 900]

On 11/5/2021 at 2:52 PM, Stefan Glienke said:

The issue with the CMR implementation is that the theoretical benefit of having less overhead is eliminated by the amount of garbage the compiler produces in some scenarios.

Version 2 in the Grijjy article works like unique_ptr in C++ but without the important feature that you cannot assign one unique_ptr to another one because well its unique (this is because the ref count is inside it and not shared across multiple references) as in

Version 3 in the Grijjy article where the ref count is shared but requires a heap allocation - Version 4 does not because it uses the monitor field but that is a hack that might break if you use it on something that uses TMonitor.

IMHO for the purposes of eliminating some boilerplate LOCs in small (<=2 screens) subroutines the implementation doesn't matter much - any will do. If SP's are supposed to live in collections, that's completely different subject