> > As a newbie, I lean towards the first argument. I want to learn about > > the boost libraries for future use, but I also feel that all coding > > resources should be as idiot proof as possible. The idea being that > > people will look at the library list and not realize that they should be > > using a specific library for a seemingly unrelated problem.
[Rob Stewart] > This is an excellent point. One doesn't go looking for a class > named "smart_ptr" or a library named "Boost.SmartPointer" when > looking to manage the lifetime of some arbitrary resource. When > one uses pointers, it makes sense. Yup. I'm glad that it is beginning to emerge that I am not alone in this conviction :-) > There can still be a smart_ptr class, even if there's a > smart_resource class. Both may be separate manifestations, > possibly sharing some implementation details, of a SmartResource > concept. Equally plausible, smart_ptr could be implemented in > terms of smart_resource somehow (derivation, aggregation, > whatever). In the Policy Based case smart_ptr would just be smart_resource (or resource_manager) with certain policies (or policy sets). Template typedefs would help a lot here. > Names are important. Witness the recent discussion about whether > pointers are resources, refer to resources, or may refer to > resources. Words convey meaning. The wrong words confuse. The > right words clarify. The same is true for names. Yes, one can > learn that "smart_ptr" means resource manager for which pointer > semantics may be appropriate. But, far better is to have > "smart_resource" and "smart_ptr" as separate classes. The latter > provides a superset of the behavior of the former, but the former > may be precisely what's needed in a given context. Agree 100% Thanks for you comments, [)o IhIL.. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
