Re: Smart pointers and delegation

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:om3vsc$jhk$1@gioia.aioe.org...
> On 2017-08-05 01:03, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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.