Re: [boost] [unnullable_ptr] Proposal for a new library

From: Angel Tsankov (fn42551_at_[hidden])
Date: 2008-08-03 16:14:09

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