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: Wed, 9 Aug 2017 17:57:11 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Wed, 9 Aug 2017 22:57:11 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="2391"; 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:47665 Date: 2017-08-09T17:57:11-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:omee2p$145a$1@gioia.aioe.org... > On 2017-08-09 02:27, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:omblk3$svi$1@gioia.aioe.org... > >>> Why would I want this, if the reference manages the object? The cardinal >>> difference is between object-managed references and reference-managed >>> objects. The former has a very limited use and would prefer to have all >>> of >>> them built-in. >> >> In that case, you definitely need to know precisely when the reference >> dies, >> so you can "manage the object". > > Right. That is the advantage of the approach. Reference's life-time is > better defined than the object's one. E.g. references can be scoped when > the object cannot. Or, more importantly, when the object must stay hidden > or is inaccessible like system resource or remote objects. > >> If you have a lifetime leak (such as any >> normal access type does), then you can't do that management safely. > > It happens when references are components of other objects and/or have > circular dependencies. Therefore strong and weak references go. > >> The pattern of the intended use-case of Implicit_Dereference does exactly >> this. > > It cannot replace smart pointer, because it does not manage the object. So > the question is whether implicit dereference can be a part of smart > pointer: > > target <-- smart pointer with implicit dereference > > This does not work for multiple reasons either. I find this surprising. It works in the use-cases I've tried. (I haven't tried a pure Smart-Pointer, although others have, since I prefer to include such things in a larger abstract - like a container). ... > So the solution could only be ugly heavy-weighted: > > target <-- smart pointer > || | > || | operation to produce helper object > || V > target <-- helper object with implicit dereference > > This has no advantages whatsoever. Ergo, implicit dereference has no use > for smart pointers. Even if true, the "real problem" however remains. If you can safely and efficiently copy the designated object, then you have no need for Implicit_Dereference. If you need "return-by-reference", though, you need some special mechanism to do that. We tried a variety of approaches, and none of them worked out that well (there are 4 alternatives for AI05-0142-1). Thus we ended up with Implicit_Dereference. Perhaps in a brand-new language, it would be possible to make a sensible definition of return-by-reference directly, but it doesn't make sense in Ada given the existing model and requirements. Randy.