comp.lang.ada
 help / color / mirror / Atom feed
From: "Alejandro R. Mosteo" <alejandro@mosteo.com>
Subject: Re: Interest in standard smart pointers for Ada 2020
Date: Sun, 3 Sep 2017 13:18:45 +0200
Date: 2017-09-03T13:18:45+02:00	[thread overview]
Message-ID: <oogo6d$jul$1@dont-email.me> (raw)
In-Reply-To: <oo90jl$1p3p$1@gioia.aioe.org>

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.



  reply	other threads:[~2017-09-03 11:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-31 12:12 Interest in standard smart pointers for Ada 2020 Alejandro R. Mosteo
2017-08-31 12:48 ` Dmitry A. Kazakov
2017-09-03 11:18   ` Alejandro R. Mosteo [this message]
2017-09-03 12:45     ` Dmitry A. Kazakov
2017-08-31 15:17 ` Lucretia
2017-08-31 15:51   ` Peter Chapin
2017-08-31 18:57     ` Lucretia
2017-09-01  9:05   ` AdaMagica
2017-09-02 14:03   ` Jere
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox