Re: [boost] Is there any interest in non-owning pointer-like types?

Subject: Re: [boost] Is there any interest in non-owning pointer-like types?
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2017-02-14 14:45:37

On Fri, Feb 10, 2017 at 3:12 AM, Joseph Thomson via Boost
<boost_at_[hidden]> wrote:
> On Fri, Feb 10, 2017 at 7:59 AM, Gavin Lambert via Boost <
> boost_at_[hidden]> wrote:
>
>> On 10/02/2017 12:24, Joseph Thomson via Boost wrote:
>>
>>> I initially read that as `caged_ptr`. I looked up the definition, and it
>>> does seem to have the right meaning. If such an uncommon word is
>>> undesirable, perhaps `obseved_ptr` or `watched_ptr` would be preferable
>>> (the "-ed" form of the veb matches `shared_ptr`).
>>>
>>
>> At the risk of devolving into a bikeshed, I don't really like anything
>> that implies observing or watching unless it has the semantics of weak_ptr
>> and knows when it is no longer pointing to a valid object.
>>
>> How about borrowed_ptr, unbound_ptr, irresponsible_ptr, unowned_ptr, or
>> not_null_ptr?  (Though a shorter typedef probably should be encouraged in
>> practice or people would likely just stick with *.)
>>
>
> A previous name I used was `indirect`, to give it an air of pointer-ness
> without using the terms "pointer" or "reference" (though it doesn't have a
> `_ptr` suffix). If we're being creative, the name could emphasise how the
> pointee is liable to die before the pointer itself.
>
> volatile_ptr

volatile int * ptr; // a volatile pointer

Rule 5 about naming - avoid "spoken ambiguity" - If I say to another
dev "you need to use a volatile pointer here" did I mean volatile_ptr
or volatile Foo * ?

> transient_ptr

I kinda like that one.

> mercurial_ptr
> unsafe_ptr
> unstable_ptr
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost