On Sunday 20 July 2003 05:30, Eugene Lazutkin wrote: > "Ross Smith" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > 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 ......... [EMAIL PROTECTED] ......... 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
