David Bradley wrote: > Q. I am not convinced. Default parameters can be used where > appropriate to hide the complexity. Again, why not policies? > A. Template parameters affect the type. See the answer to the > first question above. > > I don't get this argument. Isn't that exactly what you want. You > wouldn't want people mixing different types smart pointers.
Sometimes you don't, and you use different smart pointers. Sometimes you do want to hide implementation details from the client behind a single pointer type, and you use shared_ptr. Or, if you insist on not using shared_ptr, you use a raw pointer. > And you > definitely don't want people doing things like: > > smart_ptr<x> one; > smart_ptr<y> two; > > one = two; > > Changing T changes the type, how is that different than a secondary > template parameter? shared_ptr<T> models T*. T * create(); void destroy(T * p); You don't know or care how the T is produced. Raw pointers have no secondary parameter to encode (de)allocation details. The above interface can be expressed as shared_ptr<T> create(); No destroy() is necessary. > Maybe smart ptr's shouldn't really be passed across library > boundaries anyway. There's all kind of allocator issues and such. In > the dynamic library world, you don't want library code freeing things > allocated by the application and visa versa. So avoid policy based > smart pointers for this reason isn't going to solve the problem > anyway. shared_ptr can safely be passed across library boundaries, even in the dynamic library world. How do you write a factory function that doesn't pass a smart pointer across library boundaries? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
