Boost logo

Boost :

From: Dave Harris (brangdon_at_[hidden])
Date: 2002-04-19 22:16:20

In-Reply-To: <a9puh5$dn0$1_at_[hidden]>
On Fri, 19 Apr 2002 17:26:43 -0300 Fernando Cacciola
(fcacciola_at_[hidden]) wrote:
> It seems to me that you are baseing your argument in the assumption that
> smart pointers are used through a typedef, as in:
> typedef smart_ptr<MyClass,Policy1,Policy2,Policy3> MyClassPtr ;
> But this is not the case in many practices.

Indeed; it's not in mine. However, I am beginning to wonder if such
typedef's (or their moral equivalent) are unavoidable. We /need/ different
policies, if only for the intrusive/non-intrusive choice. Although we can
fix the policy on a per-class basis, using traits, we still need to
#include enough information to drive the traits system. I would rather not
use base classes for this, because it would mean #including "MyClass.h"
whenever a pointer to MyClass is declared, which really hurts dependency
management. But the policy has to be specified somehow. I can't think of
anything better than a short header containing just a typedef like the
above, or a traits specialisation for MyClass, which is no better.

Incidently, I don't much like having long names for such commonly used
things as pointers. My local smart_ptr is actually called CPtr, but this
still leads to names like Kernel::CPtr<Raster::CBitmap>, which is rather
long. I can't avoid my heavy use of namespaces. These names are part of
interfaces, so they appear in headers, so I don't like to use
using-declarations to cut out the Raster:: and Kernel:: parts. I could use
using-declarations in .cpp files, but then they wouldn't match the
headers. I don't like to have different names for the same thing, and
anyway it confuses DOxygen.

So I am tempted to use a typedef to shorten the name, even if I don't use
it to specify policy. Even if it is only:
    typedef boost::smart_ptr<Raster::CBitmap> CBitmapPtr;

And it is just about worth putting something like this into its own
header, along with a forward declaration of namespace Raster {class
CBitmap;} and a #include "boost/smart_ptr.h". And once it is tucked away
into a header, it doesn't much matter how verbose the typedef is.

> If we had template typedefs, then our whole argument would be wrong...
> but that feature is not available.

Well, I doubt there will be many combinations of policies in any given
project. I wouldn't be too bothered by:

    template <typename T>
    struct intrusive_ptr : public smart_ptr<
             Policy1,Policy2,Policy3> {
         // Replicate constructors etc here.

where the body of the template consists of trivial forwarding functions,
and Policy1 etc are project-wide defaults. It's not nice, and I'd rather
have a template typedef, but I can live with it meanwhile.

-- Dave Harris

Boost list run by bdawes at, gregod at, cpdaniel at, john at