Re: Smart pointers and delegation

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2017-08-10 00:57, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:omee2p$145a$1@gioia.aioe.org...

>> 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).

It will have a discriminant, to start with. Smart pointer must be 
aggregation-friendly.

>> 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.

I don't want

    A (I) := X;

taken literally. That is an abstraction inversion. I want it compiled 
into more useful

    Set (A, I, X);

My design of containers is that I effectively put a reference in the 
form of a smart pointer into the container. I don't need return by 
reference because I return a smart pointer, which is definite and 
non-limited. I have no problem with life time because the reference 
holds the object. I less problems with concurrent updates because the 
reference has a count so that the update may deploy a transaction 
scheme. And I tend to hide the referenced object type from public 
interface to make it more safe.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de