[boost] Re: Proposed smart_handle library

From: John Madsen (johnmadsen_usenet_at_[hidden])
Date: 2003-07-21 23:20:54

Anthony Liguori <anthony_at_[hidden]> wrote:
>Being primarily a Unix developer, I think this library could have a 
>great use in Unix as long as it can do a few things.  Namely, it needs 
>to be flexible enough to deal with C style inherent (i.e. it should 
>allow for custom features for socket type but I should also be able to 
>use file descriptor features for that same type since a socket is a file 
>descriptor).
>
>I think a policy based design would be interesting to pursue here.
>

I'm glad it looks useful to you.  I've addressed some of these points below.

[snip]
>>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; }
>>};
>>typedef scoped_handle<win_file_handle> scoped_win_file_handle;
>>
>>This type would be unrelated to, for example, a Windows HBITMAP, although 
>>both 
>>HANDLE and HBITMAP are void*s.
>>
>But the above would be valid for HBITMAPs since what you're declare is 
>really only specific to HANDLEs.  an win_bitmap_handle traits class 
>would be identical to the above wouldn't?  So should I just typedef 
>win_file_handle win_bitmap_handle?  Then we're back to square 1.
>

HBITMAP uses a different release method, but that's not too important.  Even 
two handles that are of logically different types, but whose traits classes are 
identical, could be easily distinguished by the type system using inheritance.  
For example,

struct win_handle { /* all members as above */ };
struct win_file_handle : win_handle {};
struct win_file_mapping_handle : win_handle {};

scoped_handle<win_file_handle> and scoped_handle<win_file_mapping_handle> are 
completely unrelated types now.  This also saves quite a bit of typing, which 
people seem to be big fans of.

>>- Semantically, handles simply aren't pointers.  E.g, the pointer deference 
>>operators make no sense for handles.
>>  
>>
>But if you think of think of a smart handle as a container containing a 
>C type, then it makes a little more sense.
>

Perhaps, but operator-> still makes no sense.

>The biggest problem is that for win_file_handle for example, it's 
>probably almost as easy to just implement a wrapper class that provides 
>a constant interface than to use smart_handles.
>

The traits class is very straightforward and trivial to implement -- much more 
so than a full handle wrapper in my opinion.  Further, much of the redundancies 
can be eliminated by inheritance as in the above example. 

>I like the initial implementation.  I've included a small sample of a 
>similiar class as a proof-of-concept of adapting smart_handle to be a 
>little more flexible and easier to use.  The main differences are:
>
>- A policy based design to whereas the policy extends the classes interface.
>- Stronger typing (the types are different based on typename, not on 
>traits).  The traits approach seems fundamentally flawed as two separate 
>types could share the same traits.
>

I think that the traits system makes the typing stronger.  It guarantees 
distinct types even in the face of handles that are otherwise 
indistinguishable.  I looked at your design, but I think I can handle what 
you're trying to do through traits class inheritance.  I don't see any use to 
extending the interface through a policy class.  Let me know if I've missed 
something.

John