add std::nonowning_ptr<> to complement std::unique_ptr<>

[Victor....@ncl.ac.uk]

Problem: annoyingly, std::unique_ptr<> cannot be passed to a function by value.

 

Consider "old C++" code:

 

void process(Widget* w){

  w->do_something();

  delete w; // nasty run-time error: w will be deleted again

}

 

void main(){

  Widget* w=new Widget();

  process(w);

  delete w;

}

 

Let's try to rewrite it with std::unique_ptr<>:

 

//void process(unique_ptr<Widget> w){ // problem - unique_ptr cannot be passed by value!

void process(unique_ptr<Widget>& w){ // extra level of indirection - potentially inefficient

  w->do_something();

  delete w; // syntax error now - good

}

 

void main(){

  auto w=make_unique<Widget>();

  process(w);

  // delete w; - no longer needed

}

 

Solution: Add a new class std::nonowning_ptr<> representing a pointer that does not own a resource (it plays a similar role as weak_ptr<> to shared_ptr<>).

 

Requirements:

  Template std::nonowning_ptr<T*> wraps T*, and is:

 

  - constructable and assignable from T*, nullptr, std::unique_ptr<T*>, and another std::nonowning_ptr<T*>, with the appropriate type casts allowed, `const' handled properly, and `explicit' used wherever needed

 

  - application of `delete' to it should trigger a syntax error

 

  - has the usual pointer operations: *, ->, comparisons, explicit operator bool()

 

  - has the get() member function yielding the stored raw pointer

 

  - a partial specialisation for T[] might be appropriate

 

  - maybe something else - suggestions are welcome.

 

Now the code looks like:

 

// the nonowning_ptr<Widget> parameter, unlike Widget*, makes it clear

// that the function will not free the resource - good for readability

void process(nonowning_ptr<Widget> w){ // no extra indirection - good

  w->do_something();

  delete w; // still a syntax error - good

}

 

void main(){

  auto w=make_unique<Widget>();

  process(w); // conversion to nonowning_ptr - this is 0-overhead

  // delete w; - no longer needed

}

 

Drawbacks: the resource could be used via nonowning_ptr<Widget> after the parent unique_ptr freed it - but that has forever been the case for raw pointers.

[Nevin Liber]

On 7 July 2013 15:43, <Victor....@ncl.ac.uk> wrote:

 

Solution: Add a new class std::nonowning_ptr<> representing a pointer that does not own a resource (it plays a similar role as weak_ptr<> to shared_ptr<>).

-1

If you are already editing code to take advantage of this, just don't call delete.  Heck, good code rarely calls delete *anywhere* except in the deleter of a smart pointer.

It seems like a lot of complexity (for users and not just the library) with very little benefit.  Of course, if there are existing implementations with years of experience already, I'm willing to reconsider.

--
 Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404

[Ville Voutilainen]

On 7 July 2013 23:43, <Victor....@ncl.ac.uk> wrote:

Problem: annoyingly, std::unique_ptr<> cannot be passed to a function by value.

Yes it can.
 

 

Consider "old C++" code:

 

void process(Widget* w){

  w->do_something();

  delete w; // nasty run-time error: w will be deleted again

}

 

void main(){

  Widget* w=new Widget();

  process(w);

  delete w;

}

 

Let's try to rewrite it with std::unique_ptr<>:

 

//void process(unique_ptr<Widget> w){ // problem - unique_ptr cannot be passed by value!
 

void process(unique_ptr<Widget>& w){ // extra level of indirection - potentially inefficient

  w->do_something();

  delete w; // syntax error now - good

}

 

void main(){

  auto w=make_unique<Widget>();

  process(w);

  // delete w; - no longer needed

}

If you change the call process(w); to process(move(w)); it works just fine, even when process takes a unique_ptr
by value.
 

 

Solution: Add a new class std::nonowning_ptr<> representing a pointer that does not own a resource (it plays a similar role as weak_ptr<> to shared_ptr<>).

See "A Proposal for the World's Dumbest Smart Pointer",
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3514.pdf

[Jeffrey Yasskin]

I'd rather not. Widget* needs to become equivalent to
nonowning_ptr<Widget> in idiomatic C++11.

On Sun, Jul 7, 2013 at 1:43 PM, <Victor....@ncl.ac.uk> wrote:
> Problem: annoyingly, std::unique_ptr<> cannot be passed to a function by
> value.

Pass the result of std::unique_ptr<>::get()

> Consider "old C++" code:
>
> void process(Widget* w){
> w->do_something();
> delete w; // nasty run-time error: w will be deleted again
> }
>
> void main(){
> Widget* w=new Widget();
> process(w);
> delete w;
> }
>
> Let's try to rewrite it with std::unique_ptr<>:
>
> //void process(unique_ptr<Widget> w){ // problem - unique_ptr cannot be
> passed by value!
> void process(unique_ptr<Widget>& w){ // extra level of indirection -
> potentially inefficient
> w->do_something();
> delete w; // syntax error now - good

Seeing "delete" is a yellow flag in idiomatic C++11. Instead, process
should take a Widget* or Widget& and know not to delete it, just like
you know not to delete the address of a reference. Perhaps compilers
will start warning about this someday.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposal...@isocpp.org.
> To post to this group, send email to std-pr...@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>

[Victor....@ncl.ac.uk]

On Monday, July 8, 2013 6:17:28 PM UTC+1, Nevin ":-)" Liber wrote:

 

If you are already editing code to take advantage of this, just don't call delete.  Heck, good code rarely calls delete *anywhere* except in the deleter of a smart pointer.

 

I don't understand your comment - one simply cannot call delete for nonowning_ptr, this will cause syntax error. The delete in the example was to demonstrate how rewriting of "old c++" code turns a run-time error to a syntax one.

 

Also, the main point of nonowning_ptr is to solve the problem of passing unique_ptr to functions without the overhead of an extra level of indirection.

 

 

It seems like a lot of complexity (for users and not just the library) with very little benefit.  Of course, if there are existing implementations with years of experience already, I'm willing to reconsider.

 

The implementation is very similar to unique_ptr, just simpler (no deleter).

 

Victor.

 

[Martinho Fernandes]

On Mon, Jul 8, 2013 at 7:32 PM, <Victor....@ncl.ac.uk> wrote:
> Also, the main point of nonowning_ptr is to solve the problem of passing
> unique_ptr to functions without the overhead of an extra level of
> indirection.

Wait, *what* problem exactly? The only situation where you have that
problem is when you bring it upon yourself. It does not arise
naturally.

Functions that deal with ownership needs to take ownership-related
arguments. Functions that don't deal with ownership *must not* take
ownership-related arguments.

Functions that operate on a T but don't deal with ownership should
have the same signature as usual: f(T&) or f(T const&), or similar
with pointers. C++11 or unique_ptrs don't change that. Functions that
operate on a T but don't deal with ownership are just *normal*. You
pass them references to objects, not ownership handles.

[Ville Voutilainen]

On 8 July 2013 20:41, Martinho Fernandes <martinho....@gmail.com> wrote:

Functions that operate on a T but don't deal with ownership should
have the same signature as usual: f(T&) or f(T const&), or similar
with pointers. C++11 or unique_ptrs don't change that. Functions that
operate on a T but don't deal with ownership are just *normal*. You
pass them references to objects, not ownership handles.

We have handle that completely transfers/holds ownership (unique_ptr), we have a handle
that shares ownership (shared_ptr), but we have no handle that doesn't transfer/hold ownership
at all. T* does all of that and none of that depending on how people use it, and fails to convey
the semantics at a glance in a function signature. Therefore I think it would be a good idea

to add what Walter Brown has proposed, aka a non-owning "smart" pointer. Not to mention
that he has also proposed the other missing piece of our puzzle, aka the value_ptr,
"A Preliminary Proposal for a Deep-Copying Smart Pointer",
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3339.pdf

[Victor....@ncl.ac.uk]

See "A Proposal for the World's Dumbest Smart Pointer",
http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3514.pdf

 

Ok, looks like I'm re-inventing the wheel. Thanks for pointing this document out to me.

 

The current proposal does not have constructors/assignment from unique_ptr, but they do mention the possibility of being aware of other pointers.

 

Anyway, no point to pursue this any further, let's kill the topic.

 

Victor.

[Nevin Liber]

On 8 July 2013 12:51, Ville Voutilainen <ville.vo...@gmail.com> wrote:

We have handle that completely transfers/holds ownership (unique_ptr), we have a handle
that shares ownership (shared_ptr), but we have no handle that doesn't transfer/hold ownership
at all. T* does all of that and none of that depending on how people use it, and fails to convey
the semantics at a glance in a function signature.

Then why isn't such a thing in wide use?  Unlike shared_ptr (not trivial to implement) or unique_ptr (required a language change to implement) and is fairly simple to implement.  Where is the existing practice to standardize?

[Ville Voutilainen]

Right here: http://qt-project.org/doc/qt-4.8/qpointer.html

[Martinho Fernandes]

That looks like a weak_ptr.

[Ville Voutilainen]

On 8 July 2013 21:02, Martinho Fernandes <martinho....@gmail.com> wrote:

>
>
> Right here: http://qt-project.org/doc/qt-4.8/qpointer.html
>

That looks like a weak_ptr.

They have an actual weak_ptr here: http://qt-project.org/doc/qt-4.8/qweakpointer.html.

The observation of deletion in QPointer may be weak-pointer-like, but it's not otherwise
related to the shared_ptr counterpart they have, QSharedPointer. For the things
we are discussing here, QPointers are used when people want to pass non-owning
smart pointers around without passing ownership and to avoid the lack of semantics
that T* suffers from. QPointer is restricted to QObjects, so it's not exactly what
we're looking for.

[Martinho Fernandes]

But would QPointer have use if it didn't have the ability to check
validity and was purely for semantic value? I see the validity check
as an interesting feature, but I don't see much value in the same
thing stripped of that ability.

[Ville Voutilainen]

On 8 July 2013 21:18, Martinho Fernandes <martinho....@gmail.com> wrote:

But would QPointer have use if it didn't have the ability to check
validity and was purely for semantic value? I see the validity check

Yes (imho), as would a non-owning "smart" pointer in general, because it tells
people at-a-glance what the ownership transfer (or more precisely, the lack of
it) is. T* doesn't do that. T& doesn't work for cases when the incoming value

may be non-existent. optional<reference_wrapper<T>> comes close, if we
want to look for a decent alternative.

[Ville Voutilainen]

On 8 July 2013 21:22, Ville Voutilainen <ville.vo...@gmail.com> wrote:

Yes (imho), as would a non-owning "smart" pointer in general, because it tells
people at-a-glance what the ownership transfer (or more precisely, the lack of
it) is. T* doesn't do that. T& doesn't work for cases when the incoming value

may be non-existent. optional<reference_wrapper<T>> comes close, if we
want to look for a decent alternative.

Then again, optional<reference_wrapper<T>> doesn't behave like a pointer,
and neither does optional<T*>. They protect against attempts to delete,
but they lack the other pointer-like syntax characteristics.

[Jeffrey Yasskin]

Ah, Chromium has a "WeakPtr" that serves the same purpose:
https://code.google.com/p/chromium/codesearch/#chromium/src/base/memory/weak_ptr.h.

It's very different from a std::weak_ptr in that the underlying object
doesn't need to be refcounted, but it's very useful in its own right.
It's definitely *not* the same thing as nonowning_ptr, since it has
overhead, and Chromium uses T* to mean "non-owning pointer" (at least
in places we haven't switched over to scoped_ptr (a C++98 emulation of
unique_ptr: https://code.google.com/p/chromium/codesearch/#chromium/src/base/memory/scoped_ptr.h)).

Jeffrey

[Jeffrey Yasskin]

Um, I mean that T* means "non-owning pointer", except in places where
it means "owning pointer" because we haven't yet switched everything
over to scoped_ptr.

[Thiago Macieira]

On segunda-feira, 8 de julho de 2013 20.02.17, Martinho Fernandes wrote:
> >> Then why isn't such a thing in wide use? Unlike shared_ptr (not trivial
> >> to implement) or unique_ptr (required a language change to implement) and
> >> is fairly simple to implement. Where is the existing practice to
> >> standardize?>
> > Right here: http://qt-project.org/doc/qt-4.8/qpointer.html
>
> That looks like a weak_ptr.

QPointer is a weak pointer. The implementation in Qt 5 is actually using a
QWeakPointer. The big difference from QWeakPointer is that you *can* construct
a QPointer from a raw pointer, but you can't do that with QWeakPointer -- it
has to come from a QSharedPointer, since something must own at least one
reference.

You may be interested in these classes too:

WTF::RefPtr - intrusive pointer / internal reference counting
WTF::PassRefPtr - passing RefPtr
WTF::OwnPtr - no reference counting, like unique_ptr
WTF::PassOwnPtr - passing OwnPtr
https://trac.webkit.org/browser/trunk/Source/WTF/wtf/PassOwnPtr.h and others

There doesn't seem to be a class for external reference counting.

Unfortunately, the documentation is quite lacking.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Ville Voutilainen]

On 8 July 2013 22:04, Jeffrey Yasskin <jyas...@google.com> wrote:

Um, I mean that T* means "non-owning pointer", except in places where
it means "owning pointer" because we haven't yet switched everything
over to scoped_ptr.

Well, in each and every project I have worked on, whenever any of

T* f(U*);

void f(T*);

T* f();

T* member;

appears, code reviewers start asking questions about ownership, without exception.

It would actually save time and money to have a standardized vocabulary type that
says "ownership is not transferred". The existing practice for these is to consider whether
it's worth the trouble to add a custom non-transferring dumb pointer (which has to be
separately taught since people won't recognize it from other projects), or to just comment
the signatures and hope for the best, usually picking the latter, and then debugging

like mad. I'd love to have both of Walter's proposals, and then just leave intrusive pointers
and externally refcounted pointers outside the standard if need be. But both the non-owning

and the cloning pointers often appear necessary, and seem like they could be tools that

developers might happily adopt. I sure as hell would.

[Jeffrey Yasskin]

On Mon, Jul 8, 2013 at 1:11 PM, Ville Voutilainen
<ville.vo...@gmail.com> wrote:
>
>
>
> On 8 July 2013 22:04, Jeffrey Yasskin <jyas...@google.com> wrote:
>>
>>
>> Um, I mean that T* means "non-owning pointer", except in places where
>> it means "owning pointer" because we haven't yet switched everything
>> over to scoped_ptr.
>>
>>
>
> Well, in each and every project I have worked on, whenever any of
> T* f(U*);
> void f(T*);
> T* f();
> T* member;
> appears, code reviewers start asking questions about ownership, without
> exception.

I'd like to double-check that these projects were started after C++11
was released and that they use std::unique_ptr, std::shared_ptr, or
some other smart point to hold every owned pointer?

If your experience (like most of ours) is still mostly on transitional
projects, I do agree that the exempt_ptr would save some communication
time during the transition, but it won't speed up the transition to
unique_ptr, and I expect that once we're done with the transition,
exempt_ptr will just be a verbose wart.

Jeffrey

[Nevin Liber]

On 8 July 2013 15:11, Ville Voutilainen <ville.vo...@gmail.com> wrote:

On 8 July 2013 22:04, Jeffrey Yasskin <jyas...@google.com> wrote:

Um, I mean that T* means "non-owning pointer", except in places where
it means "owning pointer" because we haven't yet switched everything
over to scoped_ptr.

Well, in each and every project I have worked on, whenever any of

T* f(U*);

void f(T*);

T* f();

T* member;

appears, code reviewers start asking questions about ownership, without exception.

It would actually save time and money to have a standardized vocabulary type that
says "ownership is not transferred". The existing practice for these is to consider whether
it's worth the trouble to add a custom non-transferring dumb pointer (which has to be
separately taught since people won't recognize it from other projects), or to just comment
the signatures and hope for the best, usually picking the latter, and then debugging

like mad.

So, why haven't you introduced it to your code base?  I don't mean that facetiously.  I would not want to adopt something like this into the standard without significant user experience, because in some sense developers will assume we are dictating this as a best practice for 2017 and beyond.

In my code bases, raw pointers are rare and usually used for calling C APIs, for which all this becomes is noise.

[Róbert Dávid]

2013. július 8., hétfő 22:26:56 UTC+2 időpontban Nevin ":-)" Liber a következőt írta:

In my code bases, raw pointers are rare and usually used for calling C APIs, for which all this becomes is noise.

--

Just for curiosity, do you never need reseat-able references, or do you simply use std::reference_wrapper?

Regards, Robert

[Ville Voutilainen]

On 8 July 2013 23:26, Nevin Liber <ne...@eviloverlord.com> wrote:

says "ownership is not transferred". The existing practice for these is to consider whether

it's worth the trouble to add a custom non-transferring dumb pointer (which has to be
separately taught since people won't recognize it from other projects), or to just comment
the signatures and hope for the best, usually picking the latter, and then debugging

like mad.

So, why haven't you introduced it to your code base?  I don't mean that facetiously.  I would not want to adopt something like this

I have, a couple of times. In some cases it was

template <class T> struct ptr_wrap
{

    T* ptr_;

};

and there have been cases where for different reasons it was

struct TNodeHandle
{

    void* iNodeData;

};

The user experience I have for these is that they take care of the deletion issues, but don't provide

a convenient user interface for using them like pointers. For the latter, that wasn't even a design
target, though, since it's opaque. The latter actually provides another reason to avoid raw pointers;

any T******** converts to void*, even when T is itself void. It has been my user experience that
avoiding raw pointers and using non-owning wrappers protects from such conversions.

[Ville Voutilainen]

On 8 July 2013 23:22, Jeffrey Yasskin <jyas...@google.com> wrote:

> Well, in each and every project I have worked on, whenever any of
> T* f(U*);
> void f(T*);
> T* f();
> T* member;
> appears, code reviewers start asking questions about ownership, without
> exception.

I'd like to double-check that these projects were started after C++11
was released and that they use std::unique_ptr, std::shared_ptr, or
some other smart point to hold every owned pointer?

Most of them were started way before c++11, and some used auto_ptr and boost::shared_ptr

for each and every owned pointer. Some of them have used custom smart pointers for
every owned pointer, and for even non-owned pointers. Some of them have used
const auto_ptr<T>& for cases where ownership is not transferred. The experience thus far
has been, to me, that the wrapping of non-owned pointers saved a lot of time both
avoiding clients erroneously attempting to delete, and also with the other point that I made in my
reply to Nevin, avoiding conversions to void*. The case of const auto_ptr<T>& was
that it didn't achieve what it attempted to, which is clarity and readability of interfaces,
and whenever that was passed into classes, those classes had to get() the pointer
and store it into a non-owning handle or raw pointer anyway, since there was no
usable non-owning dumb pointer available. I don't see c++11 changing that.

If your experience (like most of ours) is still mostly on transitional
projects, I do agree that the exempt_ptr would save some communication
time during the transition, but it won't speed up the transition to
unique_ptr, and I expect that once we're done with the transition,
exempt_ptr will just be a verbose wart.

The thing is that I'm talking about cases where unique_ptr will not be the final type to be used.

I have done large conversions from raw pointers to shared pointers and auto_ptr. Going from those
auto_ptrs to unique_ptr is a piece of cake. What to do with the leftover cases where ownership
isn't transferred is the harder part. Trying to treat raw T* as that non-transferring vocabulary
type has proven to be hard.

[Nevin Liber]

Within a function call, I rarely need reseatable references. Having to reseat the reference is an indicator that the function is doing too much work.

As a member variable, I'll use raw pointers over references so as not to break assignability.  reference_wrapper is certainly another way to indicate this, but I find it noisy unless you need the reference syntax in another context.

[Jeffrey Yasskin]

Ok, that sounds like solid and applicable experience. Thanks.

[Klaim - Joël Lamotte]

I just wanted to add some data: I have the same kind of experience than Ville.

First thing to note is that boost already provided the smart pointers but unique_ptr, as already pointed, so the previous codebases are still relevant if upgraded to use current tools.

However, all projects I began with C++11 features enabled have this kind of mechanism:

class A {};

class K

{

    std::map< Id<A>, std::unique_ptr<A> > m_objects;     // own A objects

    std::vector< A* > m_object_list;                                  // refer to owned A objects in a specific order that can change often

};

// OR

class ObjectRegistry // references a specific set of A objects

{

    std::map< Id<A>, A* > m_index;

public:

    void add( A& a ); // we want a valid A instance but we don't want to keep ownership

    void remove( const Id<A>& id ); // just remove the reference

}; // this might be associated to a custom smart pointer which automatically call the add() and remove() functions.

Assume that ObjectRegistry is used in contexts where the add/remove operations are called at high frequency

Often, in my experience, this kind of system is used over a pool system, where the pool own the data and

set it up in a way that helps working with it (like in arrays for data-centric approaches), then references

to that data are pushed into other systems to use it, but they never own the data.

I have basically two kind of setup where I see this:

 - in an explicitely concurrent system, then shared_ptr/weak_ptr is the right tool there;

 - in non-concurrent system, shared_ptr/weak_ptr could be used but adds a cost required by concurrent contexts but not by non-concurrent ones, which can hit hard in some contexts;

So currently I prefer to use raw pointers for non-owning resettable references when in non-concurrent systems.

Indeed it often causes confusion with coworkers: banning totally using new/delete and saying that if there is a naked pointer it's a non-owning reference helps a lot

but it apparently still invoke doubts in minds used to see pointers as a too-flexible tool.

So to me, both clarification of intent and using the right tool in high performance context are reasons why I'd like to see how such a proposal would go.

By the way, what were the reactions on the official mailing list (which is not readable publicly)  to N3514 and N3339?

Joel Lamotte

[Ville Voutilainen]

On 9 July 2013 00:21, Klaim - Joël Lamotte <mjk...@gmail.com> wrote:

By the way, what were the reactions on the official mailing list (which is not readable publicly)  to N3514 and N3339?

I can't find any in-meeting discussions on either of them. Walter wasn't present in either Portland or Bristol.

These papers need a champion...

[Nevin Liber]

On 8 July 2013 16:33, Ville Voutilainen <ville.vo...@gmail.com> wrote:

I can't find any in-meeting discussions on either of them. Walter wasn't present in either Portland or Bristol.

I thought Walter was in Portland.

I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was one of the very last things discussed).  The sentiment in the room was that it should be investigated, along with other slightly different smart pointers (such as dumb but moveable).

I don't think clone_ptr has been discussed since Kona.
 

These papers need a champion...

I assume Walter will be at the Chicago meeting, given he is relatively local.

[Ville Voutilainen]

On 9 July 2013 00:43, Nevin Liber <ne...@eviloverlord.com> wrote:

On 8 July 2013 16:33, Ville Voutilainen <ville.vo...@gmail.com> wrote:

I can't find any in-meeting discussions on either of them. Walter wasn't present in either Portland or Bristol.

I thought Walter was in Portland.

Me too, first, but the minutes etc. show him absent.
 

I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was one of the very last things discussed).  The sentiment in the room was that it should be investigated, along with other slightly different smart pointers (such as dumb but moveable).

I don't think clone_ptr has been discussed since Kona.
 

These papers need a champion...

I assume Walter will be at the Chicago meeting, given he is relatively local.

Good point. Then again, we'll be in c++14 NB comments up to our eyeballs in Chicago, so that may not be sufficient.

I suppose interested parties can work with Walter to get these things forward.

[Ville Voutilainen]

On 9 July 2013 00:47, Ville Voutilainen <ville.vo...@gmail.com> wrote:

On 9 July 2013 00:43, Nevin Liber <ne...@eviloverlord.com> wrote:

On 8 July 2013 16:33, Ville Voutilainen <ville.vo...@gmail.com> wrote:

I can't find any in-meeting discussions on either of them. Walter wasn't present in either Portland or Bristol.

I thought Walter was in Portland.

Me too, first, but the minutes etc. show him absent.

Scratch that. He was no longer a Fermilab delegate. He was indeed there. 

[Jonathan Wakely]

On Monday, July 8, 2013 10:43:11 PM UTC+1, Nevin ":-)" Liber wrote:

I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was one of the very last things discussed).  The sentiment in the room was that it should be investigated, along with other slightly different smart pointers (such as dumb but moveable).

More accurately (since dumb_ptr is also movable) the case I raised was a non-owning pointer that is dumb and **guaranteed to be null when moved-from**.  That is useful as a data member (rather than in function signatures) because it makes it easier to follow the Rule of Zero and is a useful building block for smarter types.

[Nevin Liber]

Instead of that being a smart pointer, I'd rather have a more general template that can be applied to any scalar type, such as (warning: this is just proof of concept code):

template<typename T, T v = T{}>
struct moveit
{
    using value_type = T;
    static constexpr const value_type moved_from_value = v;

    moveit(moveit const&) = default;
    moveit& operator=(moveit const& that) = default;
    ~moveit() = default;

    moveit(moveit&& that) : value(that.value) { that.value = v; }
    moveit& operator=(moveit&& that) { value = that.value; that.value = v; return *this; }

    moveit(value_type t = v) : value(t) {}

    value_type& get() noexcept { return value; }
    value_type const& get() const noexcept { return value; }
    operator value_type&() noexcept { return value; }
    operator value_type const&() const noexcept { return value; }

private:
    value_type value;
};

template<typename T, T* v>
struct moveit<T*, v>
{
    using value_type = T*;
    static constexpr const value_type moved_from_value = v;

    moveit(moveit const&) = default;
    moveit& operator=(moveit const& that) = default;
    ~moveit() = default;

    moveit(moveit&& that) : value(that.value) { that.value = v; }
    moveit& operator=(moveit&& that) { value = that.value; that.value = v; return *this; }

    moveit(value_type t = v) : value(t) {}

    value_type& get() noexcept { return value; }
    value_type const& get() const noexcept { return value; }
    operator value_type&() noexcept { return value; }
    operator value_type const&() const noexcept { return value; }

    T& operator*() const noexcept { return *value; }
    value_type operator->() const noexcept { return value; }

private:
    value_type value;
};

I'd also rather not combine that with blocking delete, as those are separate concerns.

[Ville Voutilainen]

On 9 July 2013 18:38, Nevin Liber <ne...@eviloverlord.com> wrote:

On 9 July 2013 05:14, Jonathan Wakely <c...@kayari.org> wrote:

On Monday, July 8, 2013 10:43:11 PM UTC+1, Nevin ":-)" Liber wrote:

I know that dumb_ptr was briefly discussed in Bristol in LEWG (it was one of the very last things discussed).  The sentiment in the room was that it should be investigated, along with other slightly different smart pointers (such as dumb but moveable).

More accurately (since dumb_ptr is also movable) the case I raised was a non-owning pointer that is dumb and **guaranteed to be null when moved-from**.  That is useful as a data member (rather than in function signatures) because it makes it easier to follow the Rule of Zero and is a useful building block for smarter types.

Instead of that being a smart pointer, I'd rather have a more general template that can be applied to any scalar type, such as (warning: this is just proof of concept code):

At any rate, I'd prefer dumb_ptr not zeroing the original when moved from. A zeroing-when-moved-from wrapper
seems like a completely different type to me, and I'd prefer it being so. I don't believe we should provide that
zeroing in dumb_ptr.

[Jonathan Wakely]

On Tuesday, July 9, 2013 4:38:46 PM UTC+1, Nevin ":-)" Liber wrote:

More accurately (since dumb_ptr is also movable) the case I raised was a non-owning pointer that is dumb and **guaranteed to be null when moved-from**.  That is useful as a data member (rather than in function signatures) because it makes it easier to follow the Rule of Zero and is a useful building block for smarter types.

Instead of that being a smart pointer, I'd rather have a more general template that can be applied to any scalar type,

I do have a more general class template, but it sets moved-from values to their value-initialized state (so supports anything that is DefaultConstructible.) It hadn't occurred to me to use a non-type template parameter as the moved-from value, thanks.