Re: [Boost-users] non nullable smart pointers

Subject: Re: [Boost-users] non nullable smart pointers
From: Brendan Miller (catphive_at_[hidden])
Date: 2008-11-19 17:29:58

On Mon, Nov 17, 2008 at 1:00 AM, Thorsten Ottosen
<thorsten.ottosen_at_[hidden]> wrote:
> Brendan Miller skrev:
>>
>> On Sat, Nov 15, 2008 at 2:49 AM, Thorsten Ottosen
>> <thorsten.ottosen_at_[hidden]> 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