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: Joseph Thomson (joseph.thomson_at_[hidden])
Date: 2017-02-01 10:25:11

On Wed, Feb 1, 2017 at 11:07 PM, Brook Milligan <brook_at_[hidden]> wrote:

>
> > On Feb 1, 2017, at 12:47 AM, Joseph Thomson <joseph.thomson_at_[hidden]>
> wrote:
> >
> > 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*`:
>
> From my own experience, which includes writing my own version of exactly
> what you are describing and using it extensively in a large code base, I
> wholeheartedly agree with your sentiment and would welcome a standardized
> version of this.  Just as std::unique_ptr and std::shared_ptr explicitly
> document their semantics, so too does observer_ptr, therefore making the
> code clearer to readers, users, and maintainers.  Large code bases are
> always maintained by more than one person, and unless everyone agrees on
> the meaning of T* there can be confusion, subtle errors, and maintenance
> problems.  The idea of an observer_ptr class avoids that and enables legacy
> code to be transformed at will.
>

Exactly. I have heard it suggested that once all other uses are covered by
high-level types, the only use case left for `T*` is as a non-owning
pointer. Even ignoring the real safety benefits a well-designed "observer"
type brings, this idea is flawed because:

   1. This is just a convention; no one is forced to follow it.
   2. Even if everyone did follow it, legacy code will still use `T*` for
   other purposes.
   3. Even if all legacy code were updated, low level code still uses `T*`
   for other purposes.

If it would be helpful, I would be happy to contribute anything from my own
> incarnation of an observer_ptr.  Perhaps merging ideas would ensure that
> the API handles use cases well.
>

While I was just floating the idea and a review process has not officially
started, I would be happy to hear any ideas you have. Have you seen my
implementation that I linked to in my OP?

Something that you did not mention that I have found useful is a
> make_observer() function for construction.  This is mostly useful to
> explicitly construct an observer when that helps code clarity.
>

My messages are moderated as I am a new subscriber to the list, so they may
not have gone through yet, but I have mentioned that I have a
`make_observer` function. If people feel that implicit conversion from `T&`
is bad, it could even be the primary way to construct an `observer`.

Given the increased clarity and decreased ambiguity I have seen in my code
> when using this (isn’t that ultimately the goal of the STL and other
> designed libraries?), I have always wondered about the antipathy this idea
> faces, so I hope your proposal makes better progress.
>

Indeed. I was surprised when I found out the C++ standards committee was so
hostile to the idea. I'm glad that people seem receptive to the idea here.