Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)

Subject: Re: [boost] [smart_ptr] Interest in the missing smart pointer (that can target the stack)
From: Nat Goodspeed (nat_at_[hidden])
Date: 2016-01-28 20:07:44

On Thu, Jan 28, 2016 at 12:20 PM, Noah <duneroadrunner_at_[hidden]> wrote:

> I propose a new smart pointer called, say "registered_ptr", that behaves
> just like a native C++ pointer, except that its value is (automatically) set
> to null_ptr when the target object is destroyed.
>
> the difference between weak_ptr and registered_ptr is
> that registered_ptr is independent, not just an appendage of shared_ptr.

Do you mean, for example, that you can create a registered_ptr to an
instance within the constructor? (I haven't looked at your
implementation.)

> registered_ptr can point to stack allocated objects (just like native C++
> pointers can),

That sounds pretty interesting!

> but at the cost of "thread safety". Referencing an object on
> another (asynchronous) thread's stack is inherently not safe, right? Some
> may be concerned with this lack of thread safety

I don't have a problem with stating that if you must share an object
between threads, you should put that object on the heap and use
shared_ptr so it will remain alive as long as any of those threads
still need it. I agree with your assertion that it's downright
dangerous for thread t1 to have a reference to an object that lives on
thread t2's stack.

> my implementation can only target
> types that can act as base classes. By default most classes can act as a
> base class, but native types like int, bool, etc. cannot.

That could be a bigger problem than it appears, given 'final' classes.

> In my case, this
> is not a big issue because TRegisteredPointer is actually part of a small
> library that includes (safer) substitutes for int, bool and size_t that can
> act as base classes.

Um... I'm not sure people would regard use of those substitutes as an
acceptable requirement for working with registered_ptr.

> Of course the ideal would be smart pointers that could distinguish between
> stack allocated objects and heap allocated objects. Unfortunately, as far as
> I know, (standard) C++ doesn't seem to give us that facility.

Heh. I've wished for some time for the ability to constrain a class:
"this cannot be static" or "this cannot be instantiated on the stack"
or "this cannot be instantiated on the heap." But I've never been
sufficiently motivated to write a proposal -- or, come to that, search
through WG21 archives for an existing proposal.

A good language facility that addressed my use case should also
address yours, of course.