On Fri, Nov 14, 2008 at 7:23 PM, Emil Dotchevski wrote:

On Fri, Nov 14, 2008 at 6:16 PM, Brendan Miller wrote:

...

I'm also aware of a number of problems with the shared_ptr implementation, specifically that it creates a second allocation for the counter (the counted body problem)

Using make_shared avoids the separate allocation for the control block.

I don't see a make_shared anywhere in the boost shared_ptr documentation... http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/shared_ptr.htm Am I looking in the wrong place? Yeah, I was wondering why someone hadn't done something like this... but I don't see it documented anywhere. Also, is this in TR1/C++0x's shared_ptr? I've never seen a reference to it anywhere.

I'm not sure about documentation but make_shared is available in Boost: http://svn.boost.org/svn/boost/trunk/boost/make_shared.hpp

Also see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm and Peter Dimov's web site http://www.pdimov.com/ for more shared_ptr info.

Excellent! It would be nice if boost documented this though... no one's going to use it if they have to trawl through the header to find out about it.

On Sat, Nov 15, 2008 at 2:49 AM, Thorsten Ottosen 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? 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. Also, shared_ptr is really a mouthful, but I guess when c++0x comes out you could just do a template using to shared_ref<t> or something for those (such as myself) who want to consistently prohibit null in their code to promote type safety. Really though, if you had a non-nullable reference counted pointer, you'd also want a non-nullable unmanaged pointer, a non-nullable weak pointer, a non-nullable scoped pointer and appropriate conversions, i.e. you can assign a non-null unmanaged pointer to a non-null reference counted pointer and vice versa without a runtime null check being done. That's why I was thinking of just rolling a separate set of pointers, maybe taking shared_ptr and scoped_ptr as starting points. I don't know who the maintainer is, but i wasn't sure whether they would accept a patch with that much added complexity. Brendan

On Mon, Nov 17, 2008 at 1:00 AM, Thorsten Ottosen wrote:

Brendan Miller skrev:

...

On Sat, Nov 15, 2008 at 2:49 AM, Thorsten Ottosen 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? 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 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