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.
next prev parent 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