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]>
> > 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk