Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-02-05 19:26:55

----- Original Message -----
From: "Dave Abrahams" <dave_at_[hidden]>

> It just occurred to me that this trick only works when the underlying
> pointer type is a real pointer. In other words, if smart_ptr is to be able
> to provide array access, while wrapping arbitrary pointer-like types, an
> operator[] is still required.

Yes, you're right. My point was mostly that array support (equivalent to the
default C++ array support) can be provided with only those two things--custom
deallocator and implicit conversion to pointed-to type. Everything else is just
a safety issue regarding polymorphic objects and arrays and isn't explicitly
necessary. However, on a more general policy-based smart pointer front, it is a
good idea for any policy at all to be able to disable a certain interface
function (or ctor). This is fairly easy to encapsulate but is dependent on how
the policies are passed into the smart pointer template (i.e. through one
parameter as a typelist (or similar) or through multiple parameters with
defaults or through multiple parameters with arbitrary ordering).

Paul Mensonides

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