On Mon, Nov 17, 2008 at 1:00 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Brendan Miller skrev:
On Sat, Nov 15, 2008 at 2:49 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Brendan Miller skrev:
I've been interested in non nullable smart pointers for a while. I noticed a thread I wanted to check if anyone was still interested in doing it: http://lists.boost.org/Archives/boost/2008/04/135616.php
This seems like a worthwhile activity. Null is a legacy element from C that essentially breaks type safety.
FWIW, Boost.PtrContainer does not allow you to put nulls in containers; if you want nulls you have to ask for it:
boost::ptr_vector< boost::nullable<T> > vec;
I'm always shocked how many good ideas have already been implemented in boost.
I guess it would be trivial to add something like
typedef boost::shared_ptr< boost::non_null<T> > ptr_type;
which would not be default constructible, and which would throw if you inserted a null (rather than providing a check in operator->).
You're suggesting that there would be a specialization of shared_ptr for shared_ptr<boost::non_null<T>>? That's a good idea, but I have no idea on whether the maintainers of shared_ptr are willing to accept that much more complexity.
Well, full specializations is not necessary. Some simple TMP should be enough.
-Thorsten
Well, shared_ptr would need *some* custimization I believe, since it takes a type as a parameter and not a pointer to a type, so the type of the pointer used internally (nullable or non-nullable) can't be specified using the existing interface and implementation. As is, if non_null<T> where a non-null pointer to T, then shared_ptr<non_null<T>> would be a pointer to a pointer (i.e. T**). So for non-nullable smart pointers, you'd either need a policy based implementation, which shared pointer docs seem to indicate is a design choice avoided originally since it opens the door to arbitrary numbers of mutually incompatible shared_ptr's, or something specialization based. Brendan