|
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk