From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Interest in standard smart pointers for Ada 2020 Date: Sun, 3 Sep 2017 14:45:09 +0200 Organization: Aioe.org NNTP Server Message-ID: References: NNTP-Posting-Host: MajGvm9MbNtGBKE7r8NgYA.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:47911 Date: 2017-09-03T14:45:09+02:00 List-Id: 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