Specializing make_shared< T > and allocate_shared< T >
In my last post I talked about factory_type, a class that supplies a factory function make_new( ) as a static method.
(In retrospect, I suppose factory_type isn’t such a good name since it sounds like the instances are factories. Better names might be factory_made_object_type or gizmo_type.)
Anyway, the code looked like this:
# include <boost/shared_ptr.hpp>
using boost::shared_ptr;
class
factory_type
{
/* this_type alias */
private:
typedef
factory_type
this_type;
// ======== Disable Copy ============
/* disabled copy ctor */
private:
factory_type( this_type const &)
; /* no implementation */
/* disabled copy assignment */
private:
void
operator =( this_type const &)
; /* no implementation */
// ======== Factory =================
/* private default ctor */
private:
factory_type( )
{ }
/* private dtor */
private:
~factory_type( )
{ }
/* the only place where the dtor is used */
private:
struct
private_deleter
{ void
operator ()( this_type * p)
{ delete p; }
};
/* factory, only way to make these objects */
public:
static
shared_ptr< this_type >
make_new( )
{ return
shared_ptr< this_type >(
new this_type,
private_deleter( ));
}
};
Now there’s been some discussion (see here and here) about defining standard factory template functions called make_shared<T>(..) and allocate_shared<T,A>( A const &, ..) with signatures like this:
namespace std {
template< typename T >
shared_ptr< T >
make_shared( )
;
template< typename T, typename ALLOC_T >
shared_ptr< T >
allocate_shared( ALLOC_T const & allocator_inst)
;
template< typename T, typename ... ARG_Ts >
shared_ptr< T >
make_shared( ARG_Ts && ... args)
;
template< typename T, typename ALLOC_T, typename ... ARG_Ts >
shared_ptr< T >
allocate_shared( ALLOC_T const & alloc_inst, ARG_Ts && ... args)
;
} /* end namespace std */
It is easy to specialize make_shared< factory_type >( ) to use our class’s private factory.
namespace std {
// specialize make_shared<T>( )
template< >
shared_ptr< factory_type >
make_shared< factory_type >( )
{ return factory_type::make_new( ); }
} /* end namespace std */
Let’s try some more complicated factories. Assume factory_type has some additional constructors and factories.
class
factory_type
{
... as declared above ...
// ======== Constructors =================
/* private default ctor */
private:
factory_type( )
;
/* private ctor */
private:
factory_type( float, void *, char = 'A')
;
/* private ctor */
private:
factory_type( double, long, std::string const &)
;
// ======== Factories =================
public:
static
shared_ptr< this_type >
make_new( )
{ return
shared_ptr< this_type >(
new this_type,
private_deleter( ));
}
public:
template< typename ... ARG_Ts >
static
shared_ptr< this_type >
make_new( ARG_Ts && ... args)
{ return
shared_ptr< this_type >(
new this_type( std::forward< ARG_Ts >( args) ...),
private_deleter( ));
}
// ======== Factories with allocators =======
public:
template< typename ALLOC_T >
static
shared_ptr< this_type >
allocate_new( ALLOC_T const & alloc_inst)
{ return
shared_ptr< this_type >(
new this_type,
private_deleter( ),
alloc_inst);
}
public:
template< typename ALLOC_T, typename ... ARG_Ts >
static
shared_ptr< this_type >
allocate_new( ALLOC_T const & alloc_inst, ARG_Ts && ... args)
{ return
shared_ptr< this_type >(
new this_type( std::forward< ARG_Ts >( args) ...),
private_deleter( ),
alloc_inst);
}
};
We’ll find it much harder to specialize make_shared<T>(..) and allocate_shared<T,A>( A const &, ..) to use these class-supplied factories that take parameters because you cannot partially specialize a templated function like you can a templated struct. Forgetting that, you might try:
namespace std {
// Illegal partial specialization of template function.
// Does not compile!!
template< typename A_T >
shared_ptr< factory_type >
allocate_shared< factory_type, A_T >( A_T const & alloc_i)
{ return factory_type::allocate_new( alloc_i); }
} /* end namespace std */
And the compiler will choke and complain. You could try to fully specialize the template function since partial specialization is illegal, but that means you have to know the type of the allocator beforehand. And allocators tend to come in many types. Another approach would be to define a separate overloaded (not specialized) template function called allocate_new, but typename T would have to be the first template parameter, and the first thing you want to do is specialize that as factory_type. So that doesn’t improve things in this case.
We could make this work if the first template parameter was used in the function’s argument list. If instead of allocate_shared< factory_type >( alloc_inst) the idiom was allocate_shared_2( factory_type::tag( ), alloc_inst) then we could define another template function around ALLOC_T and we would not have to specialize. But in this case that’s not a very attractive option.
Another probably better option is to define allocate_shared<T,A>(..) as a simple call to something like shared_ptr_maker<T>::allocate(..). Then we could specialize the template class shared_ptr_maker<T> instead of the function.
And finally, I’m not sure, but these examples may be an abuse of make_shared and allocate_shared. These were originally proposed as a way to hide use of the new operator since shared_ptr also hides delete. But looking at Peter Dimov’s code suggests the purpose of these functions may now be to implement an allocation strategy, where the intermediate object (aka the “control block”) and the target object are allocated as one chunk of memory instead of as two. If that’s so, it’s unlikely you’d provide specializations or overloads for these functions.
Class factories and shared_ptr<T>
One way to control object memory and initialization is to wrap object creation in a class factory. This is the point of the proposed make_shared<T>(..) and allocate_shared<T>(..) standard library functions.
But it is easy to roll your own simple factory function:
# include <boost/shared_ptr.hpp>
using boost::shared_ptr;
class
factory_type
{
/* this_type type alias */
private:
typedef
factory_type
this_type;
// ======== Disable Copy ============
/* disabled copy ctor */
private:
factory_type( this_type const &)
; /* no implementation */
/* disabled copy assignment */
private:
void
operator =( this_type const &)
; /* no implementation */
// ======== Factory =================
/* private default ctor */
private:
factory_type( )
{ }
/* public (unfortunately) dtor */
public:
~factory_type( )
{ }
/* factory, only way to make these objects */
public:
static
shared_ptr< this_type >
make_new( )
{ return
shared_ptr< this_type >(
new this_type);
}
};
shared_ptr< factory_type >
factory_inst(
factory_type::make_new( ));
And there you have factor_type, a tightly controlled class where all insts are created in the factory (factory_type::make_new( )) and all deletes are through shared_ptr<T>s. The private constructors means not only can we not “new” the class ourselves, we also cannot use it as a supertype. Nor can we declare a factory_type class member or stack variable.
factor_type would be improved, however, if we could ensure that only shared_ptr<T>s could access the destructor. It doesn’t work to declare the destructor private and friend class shared_ptr< this_type > because the destructor is actually called from a deleter function. However we can friend the deleter function:
class
factory_type
{
... as above ...
/* private dtor */
private:
~factory_type( )
{ }
/* the only function that calls the dtor */
friend void boost::checked_delete( this_type *);
/* factory, only way to make these objects */
public:
static
shared_ptr< this_type >
make_new( )
{ return
shared_ptr< this_type >(
new this_type);
}
};
This works fine, but you get the following warning from msvc++9.0: the inline specifier cannot be used when a friend declaration refers to a specialization of a function template. Of course you can disable this warning. It’s not very important and likely to go away in a future version of msvc++ anyway, and it may even be corrected by an optimized non-debug compile.
The nicest solution, however, is to provide a private non-templated deleter. It doesn’t issue the above warning and it feels more portable. It’s only drawback is that it slightly increases the size of the intermediate ref-count object.
class
factory_type
{
... as above ...
/* private dtor */
private:
~factory_type( )
{ }
/* the only place where the dtor is used */
private:
struct
private_deleter
{ void
operator ()( this_type * p)
{ delete p; }
};
/* factory, only way to make these objects */
public:
static
shared_ptr< this_type >
make_new( )
{ return
shared_ptr< this_type >(
new this_type,
private_deleter( ));
}
};
static_pointer_cast<T>(..) for weak_ptr<T>s
In the last post I mentioned that the following functions are not defined for weak_ptr<T> (in Boost 1_37_0):
- const_pointer_cast<T>(..)
- static_pointer_cast<T>(..)
- dynamic_pointer_cast<T>(..)
Boost is a very nice and carefully thought-out library, so these functions may be missing for a good reason. Or maybe they’re just considered not very important because weak pointers are not often passed around and copied on the stack. In any case, here is one way to define static_pointer_cast<T>(..) — the same pattern can be used for the other two functions.
# include <boost/assert.hpp>
# include <boost/shared_ptr.hpp>
# include <boost/weak_ptr.hpp>
# include <boost/pointer_cast.hpp>
namespace boost {
template
< typename TRG_T
, typename SRC_T
>
weak_ptr< TRG_T >
static_pointer_cast( weak_ptr< SRC_T > const & wp_src)
//
// This works even if the source weak_ptr is null or
// expired.
//
// No throw - this should never throw an exception.
{
// Get a shared_ptr from the weak_ptr.
// Use weak_ptr.lock( ) so this will not throw
// bad_weak_ptr if the weak_ptr is expired.
shared_ptr< SRC_T >
sp_src(
wp_src.lock( ));
BOOST_ASSERT( wp_src.expired( ) == ! sp_src);
// Cast the shared_ptr to the target type.
shared_ptr< TRG_T >
sp_trg(
static_pointer_cast< TRG_T >( sp_src));
// Auto-cast the shared_ptr< TRG_T > to the
// weak_ptr< TRG_T > return type.
return sp_trg;
}
} /* end namespace boost */
It would probably be more efficient to build this into the weak_ptr<T> class like it is built into the shared_ptr<T> class, but this will do.
Here is how you’d use static_pointer_cast<T>(..).
using boost::shared_ptr;
using boost::weak_ptr;
using boost::static_pointer_cast;
class
base_type
{ public: virtual ~base_type( ) { } };
class
derived_type
: public base_type
{ };
// Make a shared pointer that owns a new object.
shared_ptr< derived_type >
sp_derived(
new derived_type);
// Make a weak pointer to that same object.
weak_ptr< derived_type >
wp_derived(
sp_derived);
// Weak pointers upcast normally, even when they
// are null or expired.
weak_ptr< base_type >
wp_base(
wp_derived);
// Our new static_pointer_cast works with
// weak pointers.
weak_ptr< derived_type >
wp_derived2(
static_pointer_cast< derived_type >( wp_base)
);
I noticed when writing this that weak_ptr<T> does not have an automatic boolean conversion like other pointer types. You cannot write code like if ( weak_ptr_inst ).. or assert( ! weak_ptr_inst). Instead you have to use weak_ptr_inst.expired( ). This is because it would be easy to forget that a weak pointer can expire at any time, which can lead to bugs that fail only occasionally and are hard to reproduce.
// Assume weak_ptr bool operator is defined
// (which it isn't).
template< typename T >
class
weak_ptr
{
... other stuff ...
// Very simple bool operator.
operator bool( ) const { return ! expired( ); }
};
...
weak_ptr< my_class >
weak_ptr_inst(
shared_ptr_inst);
if ( weak_ptr_inst ) {
... Here you might find dangerous code that assumes
... weak_ptr_inst is set (not null, not expired).
... Code should always assume a weak_ptr can
... expire unless the same code is holding a
... shared_ptr to the same target object.
}
if ( ! weak_ptr_inst.expired( ) ) {
... This is the same as above, but it might be safer
... because the explicit call to expired( ) reminds
... us we are working with a weak_ptr, which
... doesn't fit into more common pointer patterns.
}