On Thu, Jan 28, 2016 at 12:20 PM, Noah
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.