2. In a post multi-threaded world this is a bad idea that simply wouldn't work. You need to take in consideration code context, ownership and life times of objects.
If the life time of the smart pointer is guaranteed in the current execution context you simply don't need an extra smart pointer, a reference to the original unique_ptr would do, or even a the actual raw pointer.
If you can't guarantee the life time, because your new pointer is not an owning pointer, even if you validate before use, by the time you actually use the object could already have been deleted leading you to dereference a dangling pointer.
This model doesn't work.
What you are looking for is a shared_ptr and a weak_ptr.
A weak_ptr works because the process of validation is to acquire a shared_ptr in the current context, which guarantees that by the time you use the pointer is not dangling because you have a shared_ptr that prevents it from being destroyed.
A non-owning but self zeroing smart pointer for single ownership
We need this when we want hold a persistent reference to an object already owned by a unique_ptr to use later if it is still valid. Not having it leaves us using raw pointers and we don't have a good art of preventing them from dangling (knowing if they are
still valid). Our mitigations tend to be fragile and often break. It is scary enough to deter us from doing such a thing but sometimes we have to and it is here that dangling pointers remain a huge hazard.
It doesn't have to be like that, We can have a smart pointer for the role but it will be involve intrusion on the owning unique_ptr declaration so it can notify deletes and some reference counting overhead but with that it is rock solid (valid or null). Here
is a working example:
The addition of something like this to the Standard Library would complete safe smart pointer coverage for heap allocated objects. It is the missing piece needed to do this. Its safe encapsulation of an idiom that was unreasonably hazardous will also open up
new design opportunities.
--