Hi all, This is something I have brought up before and it has come up again on the "Lock Classes" thread and I have made some new comments there, as well as some others touching on the same area:
http://aspn.activestate.com/ASPN/Mail/Message/boost/1544269 http://aspn.activestate.com/ASPN/Mail/Message/boost/1544265 http://aspn.activestate.com/ASPN/Mail/Message/boost/1544470 The crux of it, AFAICS, boils down to this: Should smart_ptr (in the case of a PBSP design, or you could substitute this with shared_ptr) be stretched to manage non-pointer (or "incidentally pointer", like certain OS handles) resources? This involves, primarily, two things: 1. That the subject template type be allowed to specify non pointer types. 2. That a custom "deleter" is made available. (I believe shared_resource and the various PBSP proposals in boost files have the provision for (2). I don't think shared_resource has (1). IIRC the PBSP proposals can make (1) available through the appropriate use of policies. Now all this sounds reasonable enough, so what am I contending here? Well the problem I see is that we are using an entity with "pointer" written all over it (the name especially, but also the primary semantics). Surely managing general resources according to RAII principles is a more general concept than managing pointers to objects? At the very least there should be a smart resource concept, perhaps embodied in a shared_resource template or, better still, a policy-based smart_resource. shared_ptr/ smart_ptr may then be specialisations or instantiations of these. I have argued previously that these concepts should be kept separate such that smart_resource is a parallel concept to smart_ptr, but recently I am inclined to agree that there is a relationship. However many (most?) of the smart_ptr proponents seem to favour assimilating the smart resource concept into smart_ptr itself! The reason I stepped in on the "Lock Class" thread was that it had been proposed that mutex locking (or more general locking) be made a policy of a policy-based smart_ptr design. This resulted the very confusion that I have been alluding to. Pointers are Resources Resources are not (all) Pointers. I know it is a busy time for many on this list, but I would like to invite further comment on this as it seems to be becoming increasingly important as PBSPs and potentially generalised lock classes move closer to adoption with boost. Best regards, [)o IhIL.. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
