[boost] Re: smart_ptr vs smart_resource

From: Anthony Williams (anthony.williamsNOSPAM_at_[hidden])
Date: 2003-02-20 11:45:39

David Abrahams <dave_at_[hidden]> writes:

> "Phil Nash" <phil.nash.lists_at_[hidden]> writes:
> 
> >     Pointers are Resources
> >     Resources are not (all) Pointers.
> 
> Actually, 
> 
>       Pointers *refer to* resources
>       Not all pointers refer to (are) resources 

How about:

        Pointers are a way of referring to resources.
        Not all ways of referring to resources are pointers.

Which (in my mind) better captures what Phil was originally saying. Of course,
not all pointers refer to a resource owned by the code with the pointer, some
are just pointers to data elsewhere. However, as I see it, this is just an
ownership issue --- either a pointer owns the resource it points to, or it
doesn't; it still points to a resource.

Likewise, some resource handles are integers; this doesn't mean that all
integers are resource handles. However, there is a lot in common between a
resource handle that is an integer and a resource handle that is a pointer ---
there needs to be a policy for deciding who owns the resource the handle
refers to, there needs to be code for manipulating the resource the handle
refers to (possibly just by passing the handle to another function), and there
needs to be a policy for releasing the referred-to resource when it is
appropriate (which may be never, for a non-owning handle). The details of the
ownership/when-to-release policies are really independent of the type of
resource being managed, and the type of handle used to manage it. On the other
hand, the resource manipulation code (including the code to release the
resource) is tightly coupled to the resource type and the handle type.

On Windows, for example, you can use GlobalAlloc to allocate some memory, and
you get an HGLOBAL back --- a handle to the memory. You need to call
GlobalLock with that handle to get a pointer to the memory which you can
actually use. The resource manager therefore needs to keep track of the
handle, rather than the pointer (which may be different after different calls
to GlobalLock, if there has been an intervening GlobalUnlock). Indeed, the
pointer to the locked memory is essentially a separate resource, acquired with
GlobalLock() and released with GlobalUnlock. It would be sensible to be able
to use the same framework for both the handle and the pointer.

Anthony
-- 
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.