Subject: Re: [boost] Is there any interest in non-owning pointer-like types?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-02-03 01:13:01
Le 01/02/2017 à 08:47, Joseph Thomson a écrit :
Hi,
thanks for bringing these classes to boost ML discussion.
> For some time, I have been developing a pair of non-owning pointer-like
> types that I am currently calling `observer_ptr` and `observer`.
I don't think observer and observer_ptr are the good names. Both are
pointers as they have pointer semantics.
I'll suggest not_null_ptr and observer_ptr
> I had
> planned to propose their addition to the C++ standard library, but I have
> been informed by the author of the original `observer_ptr` proposal
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf> that
> the ISO C++ committee has rejected his proposal and made clear that it
> feels there is no place in the standard library for such types, believing
> that this role is filled to a satisfactory degree by regular pointers. I
> wholeheartedly disagree with this assessment, so I am bringing my proposal
> here instead.
I'm confused. observed_ptr is part of the C++ Fundamental TS v2. Why do
you say that it was rejected?
> The `observer_ptr<T>` class template is a pointer-like type that does not
> do any resource management, and is intended to be used in place of `T*`
> wherever `T*` is used as a non-owning reference to an object of type `T`.
> `observer_ptr<T>` has three main advantages over `T*`:
>
> 1. `T&` is implicitly convertible to `observer_ptr<T>` which, unlike `T*`,
> makes it *type-safe*. `T*` can represent things that are not
> conceptually objects of type `T`: arrays, strings, iterators. No
> implicit conversion from `T*` means that these things cannot implicitly
> convert to `observer_ptr<T>`. Pointers aren't even required to point to
> valid objects (e.g. a past-the-end iterator). Conversely, in a well-formed
> program, `T&` is *always* a valid object of type `T`.
> 2. `observer_ptr<T>` documents its purpose. This is really a side-effect
> of it being type-safe (a type should have a single, specific purpose), but
> it's worth mentioning. Conversely, when you see `T*`, it may not be
> immediately obvious what it represents.
> 3. `observer_ptr<T>` has a minimal interface, which makes it harder to
> misuse than `T*`; for example, `observer_ptr<T>` has no pointer
> arithmetic operators, no array subscript operator, no conversion to
> `void*`.
So you have added the implicit conversion from T& to the FTSV2 observed_ptr.
Why implicit?
You have added mixed comparisons, between observed_ptr<T1> and T2. Have
you added them because the conversion was implicit?
Could you show a concrete and real a use case?
>
> The `observer<T>` class template is a counterpart to `observer_ptr<T>` that
> has *no null state*; it cannot be default constructed, constructed from
> `nullptr_t` or constructed from `T*`, and it does not contextually convert
> to `bool`. The only way to create an `observer<T>` is from `T&`. This
> allows a "not null" precondition to be enforced at compile-time, rather
> than having to worry about pointers being null at run-time.
Wondering if an explicit conversion from T*, requiring that T* is not
nullptr is not useful. This is C++.
When the user knows that the pointer is not null, it seams natural that
the user can construct an observer<T>
if (T* ptr = f())
g(observer<T>(ptr));
observer<T>(ptr) will be UB if ptr is equal to nullptr.
Or are you suggesting that the user de-reference the pointer to get a
reference
if (T* ptr = f())
g(observer<T>(*ptr);
or with a factory
if (T* ptr = f())
g(not_null(ptr);
I believe it is worth proposing the not-null observer pointer to the C++
standard.
And why not the construction from T& for observer_ptr<T>.
I don't share the get_pointer concern. smart pointer have a get function .
However I believe it is worth proposing an explicit conversion in
addition to the get function
Vicente