Re: [boost] Re: policy-based smart pointers are EVIL!

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