Alp Mestan wrote:
Now everything is okay. The compiler doesn't dislike your code anymore and I don't get any execution problem. I'm glad to hear that. However I don't see anything that would keep the nested pointer to be null. What do you mean? Moreover, don't you want unnullable_ptr users to have a ready-to-use copy constructor and = operator ? The class template and the specializations all have public copy assignment operators.
The copy constructor of the class template is private because its behaviour (copies the pointer stored in the passed unnullable ptr) is inconsistentfrom that of the other constructors (store a pointer to the passed object). For a more detailed explanation, see my post from 22.07.2008.
I'm actually wondering if using a smart pointer and adding a non-null condition checking wouldn't be prettier and faster than rewriting all from scratch.
That would add CPU overhead. unnullable_ptr avoids this. For a description of the purposes of unnullable_ptr and the restrictions I've imposed on it, please see my first post.
As you'vre written this class, you probably had the need of writing such a class. Can you give an exemple of situation where your class would solve a problem or help a lot ?
Yes, I often need a copyable member reference or alternatively a non-null member pointer. Another application of unnullable_ptr is in defensive programming. For instance, the throw version of 'operator new' never returns NULL, so why not make this explicit and make it return unnullable_ptr<void>?! (This is just an example, do not take this as an attempt to change the standard.) Regards, Angel Tsankov