From: Jason House <[EMAIL PROTECTED]> > > Well, being relatively a newbie at all this stuff, I have to admit > that the initial discussion of performing a lock using a (smart) > pointer, seemed odd to me. Someone later "clarified" that a smart > pointer doesn't need to use * and -> operators... something very > non-pointer-like to me... > > * The one argument seems to be that the name will cause confusion > > * The other argument seems to be that anyone who uses it will already > know what it means. (either the library writer who buries the > definition deep inside... or those who should "know" resource management > when they hear the term smart pointer) > > 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.
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. > It is a shame for things to simply be the way that they are simply > because they started out from a specific beginning... History always has a way of biting us. In this case, we are creating something brand new in Boost. There isn't a PBSP in boost. Therefore, if it is a manifestation of a SmartResource concept or is implemented in terms of a smart_resource class isn't as important as the recognition that it is a special case of the more abstract concept. > As far as my true stance on naming, I'm torn. I think that the > majority of the use really will be as as a pointer. It almost seems > like there can be some kind of "higher than smart pointer" resource > management feature... something that simply restricts/prevents > copying/access, and can call a custom resource freeing routine... 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). Even the name "smart_ptr" will not be commonly exposed; one will use typedefs to hide its configuration in order to leave open the possiblity for future changes to a given SP type. (Reasonable policy defaults may give a good, common SP type that can be used in most circumstances. If that's the case, then one may refer to "smart_ptr" rather frequently.) 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. > With the counter examples of pointers to non-resources, would > scoped_ptr or shared_ptr even make sense? It seems that if there's a > smart_ptr to something within another another object, the destruction of > what is pointed to will never actually be controlled by smart_ptr... I'm not sure what you're asking here. -- Rob Stewart [EMAIL PROTECTED] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
