Interest in standard smart pointers for Ada 2020

Interest in standard smart pointers for Ada 2020

[Alejandro R. Mosteo]

I wonder if there would be interest in standardizing some usual smart 
pointers for the next revision. I will try to state the problems. I hope 
you'll point any misunderstandings on my part.

Ada has the particular limited and indefinite types, typically absent in 
other languages. However, their constraints often get in the way of 
comfort (all the cases I will list have workarounds, it's only tiresome 
and unnecessary noise):

* You cannot have indefinite record members, unless you make the record 
indefinite as well by providing a constraint. This basically moves the 
problem elsewhere (to the containing record, which may have no reason to 
be indefinite). Furthermore, some types do not have public constraints 
(e.g., to prevent declaration without initialization), so the previous 
solution wouldn't work. Also for class-wide members?

*** Ada.Containers.Indefinite_Holders is aimed at this use case, but it 
is only for by-value semantics, so if you don't want to pay that penalty 
for some reason (large types) you're out of luck.

* You cannot have a limited type (obviously) as a member of an unlimited 
type. You're then forced to resort to low-level accesses or custom 
wrappers to pass around those members.

* Delayed initialization of limited types, specially in combination with 
indefinite-ness will require some access type use.

* Delayed initialization of indefinite types, when you don't want to/can 
have a default discriminant (I remember a recent discussion about 
limited-size indefinites).

* Any other use cases I'm forgetting about right now?

Arguably (I'm unsure about this) in most cases problems could be avoided 
with careful design? I don't know, but I do know that there are smart 
pointer Ada libraries around, and I have rolled my own more often than 
not, and when I try to go the unconstrained way all around, sooner or 
later I have to backpedal.

If we look at the cousin C++, the standard pointers there are:

> unique_ptr [1]

> Allows exactly one owner of the underlying pointer. Use as the default choice for POCO unless you know for certain that you require a shared_ptr. Can be moved to a new owner, but not copied or shared.

> shared_ptr [2]

> Reference-counted smart pointer. Use when you want to assign one raw pointer to multiple owners, for example, when you return a copy of a pointer from a container but want to keep the original. The raw pointer is not deleted until all shared_ptr owners have gone out of scope or have otherwise given up ownership.

> weak_ptr [3]

> Special-case smart pointer for use in conjunction with shared_ptr. A weak_ptr provides access to an object that is owned by one or more shared_ptr instances, but does not participate in reference counting. Use when you want to observe an object, but do not require it to remain alive. Required in some cases to break circular references between shared_ptr instances.

I'd argue for having these, and also thread-safe implementations (that I 
guess would be heavier, requiring protected internals). I'd be willing 
to work on this too, if there is interest.

Alex.

[1] http://en.cppreference.com/w/cpp/memory/unique_ptr
[2] http://en.cppreference.com/w/cpp/memory/shared_ptr
[3] http://en.cppreference.com/w/cpp/memory/weak_ptr

Re: Interest in standard smart pointers for Ada 2020

[Dmitry A. Kazakov]

On 31/08/2017 14:12, Alejandro R. Mosteo wrote:

[...]

My major concern is to have an ability to keep the target type private. 
To me smart pointers are useless otherwise.

Note that this preempts discussion about implicit dereference. Apart 
from that smart pointer must be non-limited there should be no visible 
dereference because the target type is private.

> I'd argue for having these, and also thread-safe implementations (that I 
> guess would be heavier, requiring protected internals).

That depends on the safety meant here. If only pointer operations 
considered, not the operations delegated to the target type operations, 
then no protected object is required. Atomic increment and atomic 
fetch-and-decrement are sufficient. Needless to say that Ada must have a 
system package with these.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Interest in standard smart pointers for Ada 2020

[Lucretia]

On Thursday, 31 August 2017 13:12:20 UTC+1, Alejandro R. Mosteo  wrote:
> I wonder if there would be interest in standardizing some usual smart 
> pointers for the next revision. I will try to state the problems. I hope 
> you'll point any misunderstandings on my part.

Yes, I've had to write these in the past too. Royal pain to keep doing.

> If we look at the cousin C++, the standard pointers there are:

Cousin?
 
> > unique_ptr [1]
> 
> > Allows exactly one owner of the underlying pointer. Use as the default choice for POCO unless you know for certain that you require a shared_ptr. Can be moved to a new owner, but not copied or shared.

I just had to look up POCO, seems to be Plain old CLR Object, don't think that's what you meant.

I would add auto_ptr too, I've implemented one before, although I think Block_Pointer would be a better Ada name for it. Should be limited, initialised with extended return and frees the contents at the end of the block in which it was instantiated.

Re: Interest in standard smart pointers for Ada 2020

[Peter Chapin]

On 2017-08-31 11:17, Lucretia wrote:

> I would add auto_ptr too, I've implemented one before, although I think Block_Pointer would be a better Ada name for it. Should be limited, initialised with extended return and frees the contents at the end of the block in which it was instantiated.
> 

FWIW, auto_ptr is depreciated in the C++ standard in favor of
unique_ptr. As I understand it, there are issues in the auto_ptr
interface that make it needlessly awkward.

Peter

Re: Interest in standard smart pointers for Ada 2020

[Lucretia]

On Thursday, 31 August 2017 16:51:26 UTC+1, Peter Chapin  wrote:
> On 2017-08-31 11:17, Lucretia wrote:
> 
> > I would add auto_ptr too, I've implemented one before, although I think Block_Pointer would be a better Ada name for it. Should be limited, initialised with extended return and frees the contents at the end of the block in which it was instantiated.
> > 
> 
> FWIW, auto_ptr is depreciated in the C++ standard in favor of
> unique_ptr. As I understand it, there are issues in the auto_ptr
> interface that make it needlessly awkward.
> 
> Peter

Well, that's C++ and their issues. But for Ada, what I stated above would work fine.

Re: Interest in standard smart pointers for Ada 2020

[AdaMagica]

Am Donnerstag, 31. August 2017 17:17:12 UTC+2 schrieb Lucretia:
> I would add auto_ptr too, I've implemented one before, although I think Block_Pointer would be a better Ada name for it. Should be limited, initialised with extended return and frees the contents at the end of the block in which it was instantiated.

Sorry, I don't know much about C++.

But in Ada, you can add a size clause to an access type declaration. The whole thing is freed when the type goes out of scope.

Then there is System.Storage_Pools.

Isn't this what you request with an auto_ptr?

Re: Interest in standard smart pointers for Ada 2020

[Jere]

On Thursday, August 31, 2017 at 11:17:12 AM UTC-4, Lucretia wrote:
> On Thursday, 31 August 2017 13:12:20 UTC+1, Alejandro R. Mosteo  wrote:
> > I wonder if there would be interest in standardizing some usual smart 
> > pointers for the next revision. I will try to state the problems. I hope 
> > you'll point any misunderstandings on my part.
> 
> Yes, I've had to write these in the past too. Royal pain to keep doing.
> 
> > If we look at the cousin C++, the standard pointers there are:
> 
> Cousin?
>  
> > > unique_ptr [1]
> > 
> > > Allows exactly one owner of the underlying pointer. Use as the default choice for POCO unless you know for certain that you require a shared_ptr. Can be moved to a new owner, but not copied or shared.
> 
> I just had to look up POCO, seems to be Plain old CLR Object, don't think that's what you meant.
> 
> I would add auto_ptr too, I've implemented one before, although I think Block_Pointer would be a better Ada name for it. Should be limited, initialised with extended return and frees the contents at the end of the block in which it was instantiated.

Out of curiosity, what feature of auto_ptr are you looking for that isn't provided by unique_ptr.  It was designed to be a more efficient replacement of auto_ptr, and it has all of the auto_ptr semantics available to my knowledge.

Re: Interest in standard smart pointers for Ada 2020

[Alejandro R. Mosteo]

On 31/08/17 14:48, Dmitry A. Kazakov wrote:
> On 31/08/2017 14:12, Alejandro R. Mosteo wrote:
> 
> [...]
> 
> My major concern is to have an ability to keep the target type private. 
> To me smart pointers are useless otherwise.

Wouldn't that be up to the instantiation? If you use a private type 
there, it will be private, right?

> Note that this preempts discussion about implicit dereference. Apart 
> from that smart pointer must be non-limited there should be no visible 
> dereference because the target type is private.

If I'm interpreting correctly, you mean that you'd want no visible 
dereference (hence implicit dereference) but that that's impossible for 
a non-limited pointer with a private target type.

I was thinking something along the following, which indeed requires the 
use of explicit getters to get a limited type that actually uses 
implicit dereference:

https://bitbucket.org/amosteo/rxada/src/361d4e2ab20a7dcca007e31bf7094d57b13fee6b/src/priv/rx-tools-shared_data.ads?at=default&fileviewer=file-view-default

Which is my adaptation and borking of 
http://www.adacore.com/adaanswers/gems/gem-107-preventing-deallocation-for-reference-counted-types/

My understanding was that you cannot make safe implicit dereferences 
with a non-limited type, but on re-reading that gem I'm unsure I grasp 
all the subtleties in there, so my code is probably not as safe as I 
thought.

>> I'd argue for having these, and also thread-safe implementations (that 
>> I guess would be heavier, requiring protected internals).
> 
> That depends on the safety meant here. If only pointer operations 
> considered, not the operations delegated to the target type operations, 
> then no protected object is required. Atomic increment and atomic 
> fetch-and-decrement are sufficient. Needless to say that Ada must have a 
> system package with these.

I meant the same as interpreted, the pointer operations.

Which doesn't preclude that I sometimes have wished to be able to do:

--  type X is private;
type X is protected private;

That would give me a vanilla protected object without having to rewrite 
everything. I know there are reasons why this is not so easy for Ada, 
but one can dream.

Re: Interest in standard smart pointers for Ada 2020

[Dmitry A. Kazakov]

On 2017-09-03 13:18, Alejandro R. Mosteo wrote:
> On 31/08/17 14:48, Dmitry A. Kazakov wrote:
>> On 31/08/2017 14:12, Alejandro R. Mosteo wrote:
>>
>> [...]
>>
>> My major concern is to have an ability to keep the target type 
>> private. To me smart pointers are useless otherwise.
> 
> Wouldn't that be up to the instantiation? If you use a private type 
> there, it will be private, right?
 >
>> Note that this preempts discussion about implicit dereference. Apart 
>> from that smart pointer must be non-limited there should be no visible 
>> dereference because the target type is private.
> 
> If I'm interpreting correctly, you mean that you'd want no visible 
> dereference (hence implicit dereference) but that that's impossible for 
> a non-limited pointer with a private target type.

I want it, but it cannot have it in public interfaces with the target 
type private. So even if implicit dereference aspect were reasonably 
designed, i.e. not imposing limitness on the reference type, it still 
would not fly.

> My understanding was that you cannot make safe implicit dereferences 
> with a non-limited type, but on re-reading that gem I'm unsure I grasp 
> all the subtleties in there, so my code is probably not as safe as I 
> thought.

There is no subtleness only a misunderstanding. Reference in implicit 
dereference is really meant to be a language reference like in by 
reference parameter passing, i.e. a short-lived temporal 
compiler-managed object. It was bad design just because such things may 
not be named explicit types.

Smart pointers are long-lived objects, they have almost nothing in 
common with references above, though they could deploy them in order to 
access target objects.

>>> I'd argue for having these, and also thread-safe implementations 
>>> (that I guess would be heavier, requiring protected internals).
>>
>> That depends on the safety meant here. If only pointer operations 
>> considered, not the operations delegated to the target type 
>> operations, then no protected object is required. Atomic increment and 
>> atomic fetch-and-decrement are sufficient. Needless to say that Ada 
>> must have a system package with these.
> 
> I meant the same as interpreted, the pointer operations.

Protected is not what is needed, because atomic operations do the job 
better.

As for task safe target operations, protected interface is again no 
solution. Target operations are potentially long and even blocking. 
Therefore you would like to have locking per a re-entrant mutex, i.e. 
two protected actions: one in the prologue, one in the epilogue, and 
normal execution in between.

> Which doesn't preclude that I sometimes have wished to be able to do:
> 
> --  type X is private;
> type X is protected private;
> 
> That would give me a vanilla protected object without having to rewrite 
> everything. I know there are reasons why this is not so easy for Ada, 
> but one can dream.

And adding protected aspect later:

    type Y is new protected X with ...;

The problem with this is making [finally] protected and task objects 
tagged and allowing derivation from. It is a big issue, which need to be 
discussed first and, as always, there is no interest in such discussions 
and language changes in general.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de