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!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Smart pointers and delegation Date: Mon, 7 Aug 2017 17:39:22 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Mon, 7 Aug 2017 22:39:23 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="27909"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:47635 Date: 2017-08-07T17:39:22-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:om3vsc$jhk$1@gioia.aioe.org... > On 2017-08-05 01:03, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:oluk0l$a8o$1@gioia.aioe.org... >>> On 2017-08-03 05:36, Randy Brukardt wrote: >> ... >>>>> ? Not even close. Adjust and Finalize are primitive operations, which >>>>> was >>>>> a horrific design choice, but nevertheless. Implicit dereference is >>>>> not >>>>> an >>>>> operation, not even a body. >>>> >>>> In the intended use, Implicit_Dereference is always combined with a >>>> controlled type, which provides the actual hooks. >>> >>> ? These are not hooks on the operation of dereferencing. >>> >>> [E.g. you cannot make a task-safe dereferencing by taking a lock at the >>> beginning and releasing it at the end, i.e. a typical Ref/Unref pair] >> >> Why not? That's precisely the sort of use that is intended. One seizes >> the >> lock when the dereference object is created (the start of the >> dereference) >> and the frees it when the dereference object is destroyed (finalized). > > What is dereference object? There is a target object X and reference > object R, both already exist. > > Let I want to pass R to an operation F of X. This should lock/unlock on > the way. I cannot do that without some third type. Right. And that's a problem how? Helper types are quite common in ADTs. >>> [...] >>>> That's the problem: the Implicit_Dereference mechanism is intended for >>>> the >>>> rare cases where "normal primitive operations" don't work (because they >>>> imply copies for function results). If "normal primitive operations" >>>> work, >>>> you don't need (and shouldn't use) any special mechanism. >>> >>> I must and I need it, because in real-life examples (e.g. #1) it is many >>> thousands lines of noise code in both package declarations and bodies. >>> Which is quite error-prone too. >> >> Sorry, I meant the mechanism as intended is only needed in limited cases. >> You have a very different use-case that has nothing whatsoever to do with >> the need for the Implicit_Dereference mechanism. I didn't intend to say >> anything about the value of that use-case. > > Implicit dereferencing semantically does the same. For each visible > operation of the target type it declares an anonymous operation of the > reference type that dereferences and then calls to the original operation. I don't see this at all. > Delegation has these operations named. [and primitive. In this sense it is > more restricted] Nothing wrong with that per-se, but I fail to see the connection. ... >> The problem is that the delegation is unsafe -- it has very different >> semantics. The use of an access discriminant in Implicit_Dereference is >> what >> gives the limited lifetime to the access type, and that makes it possible >> to >> use finalization to get control at the end of the life of the >> dereference. > > It could be an access discriminant too. But I used an access component to > illustrate that it need not to be a discriminant. > > The use-case is reference counting smart pointers. I guess you rather > meant a temporary reference into some container when the reference is > short-lived and the container element is long-lived. Correct. That was the problematic case. > Smart pointers use the opposite approach. Pointers (the last one) outlive > the targets. If a container is built then out of smart pointers, e.g. it > keeps pointers to the elements. Alternatively, it can keep raw elements > and hold a reference to each. You access elements strictly through > pointers which need not to be disposed immediately. They can live as long > as necessary. It can be used in transactional schemes, e.g. cloning > elements for mutators if the reference count > 1 etc. It's not really opposite, though, if you want to limit the lifetime of the reference (even if that limit is potentially a long time). Randy.