[boost] smart_ptr vs smart_resource

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2003-02-20 10:15:52

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..