Re: [boost] Re: Re: Proposed smart_handle library

From: Ross Smith (r-smith_at_[hidden])
Date: 2003-07-19 18:16:45

On Sunday 20 July 2003 05:30, Eugene Lazutkin wrote:
> "Ross Smith" <r-smith_at_[hidden]> wrote in message
> news:200307191124.21290.r-smith_at_ihug.co.nz...
>
> > This is easily handled; just use boost::bind(ReleaseDC, hWindow,
> > _1) for the release function.
>
> In proposed library release functionality is handled by static
> function, which is part of trait:
>
> struct win_file_handle {
>     typedef HANDLE handle_type;
>     static bool is_valid(handle_type h)
>         { return h != INVALID_HANDLE_TYPE; }
>     static void release(handle_type h)
>         { if (is_valid(h)) ::CloseHandle(h); }
>     static handle_type default_value()
>         { return INVALID_HANDLE_TYPE; }
>     static bool equal(handle_type lhs, handle_type rhs)
>         { return lhs==rhs; }
> };
>
> (This example is taken from original post by John Madsen.)

This strikes me as massive overkill. Why force the user to write a 
traits class when you can just pass the necessary information as an 
argument?

> Obviously this approach doesn't provide for solution proposed by you
> because hWindow is unknown until run time. One obvious way is to have
> release function as constructor parameter, which is going to be
> called during destruction. In this case we can use a lot of nifty
> stuff including binding. Is it good solution? Well, it depends. In
> some cases it would be too much of overhead.

Handles are essentially the same kind of resource management as smart 
pointers; the API should be as similar as possible. If the handle type 
is itself a pointer, the existing boost::shared_ptr already solves the 
problem. For handle management, all we need is a couple of templates 
that take the handle type (instead of the pointed-to type) as a 
template argument but are otherwise identical to shared_ptr and 
scoped_ptr.

The non-ref-counted version would have to take a release function as a 
constructor argument too, of course. But then I think there should be a 
type like that for pointers too, a slightly expanded scoped_ptr; I 
often find myself using shared_ptr because I need the "grin" effect 
even though I don't need the reference counting.

(Of course all of these could easily be unified into a single 
policy-based type; unfortunately the Powers That Be seem to have 
decided that policies are too complicated for us mere mortals to be 
trusted with.)

-- 
Ross Smith ......... r-smith_at_[hidden] ......... Auckland, New Zealand
  "As Unix guru types go, I'm sweet, patient, and comprehensible.
  Unfortunately, Unix guru types don't go very far in that direction.
  I used to think this was a personality flaw." -- Elizabeth Zwicky