Re: Smart pointers and delegation

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:omee2p$145a$1@gioia.aioe.org...
> On 2017-08-09 02:27, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.