From: Maxim Yegorushkin (e-maxim_at_[hidden])
Date: 2004-07-13 03:00:15
Maciej Sobczak <prog_at_[hidden]> wrote:
> It depends on how you count this "simplicity".
> For 99% cases I can think of (in fact, for 100% - the 1% margin is for
> my humble assumption that one cannot think of everything ;) ), the smart
> handle would be needed to provide exception safety to raw handles which
> manage some external resources (files, sockets, DB connections,
> sessions, statements, transactions, processes, etc.) and which automate
> their cleanup. All these resources take much more time (usually orderS
> of magnitude) to allocate and cleanup than a single new.
> I've yet to see a realistic example where such resource is significantly
> cheaper than operator new.
> And even if this is realistic, it would be easy to extend the machinery
> to use some tuned allocation strategy, like recycling memory pool, so
> that the allocation by new comes down to just few CPU cycles.
> In other words, I do not consider this solution to be an overkill.
> Moreover, it is quite cheap and can buy some interesting features - for
> example, you can change the deleter at run-time (the basic Strategy
That does make sence.
> Interesting, but I would add is_null() predicate to the traits. This is
> so that the Handle does not need to define its own operator== and
> operator!= (but you can always delegate the generic traits to these
>> class Handle
>> , class Pfn
>> , Pfn close
>> , class Tag
>> , class Traits = scoped_handle_traits<Handle>
>> class scoped_handle : private boost::noncopyable
>> typedef Tag tag_type;
> Would you please explain what is the need for Tag or tag_type?
The example is win32 handles. Being different entities they may have the same HANDLE type and are closed using CloseHandle(). I needed to make overloads on scoped_handle<> type, so as scoped_handle<> typedef for such handles would be the same type I had to add Tag template parameter.
-- Maxim Yegorushkin
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk