----- Original Message ----- From: "Dave Abrahams" <[EMAIL PROTECTED]>
> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
