Boost logo

Boost :

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-05-08 21:02:48


At 9:57 PM -0600 5/7/01, Rainer Deyke wrote:
>----- Original Message -----
>From: "Jesse Jones" <jesjones_at_[hidden]>
>To: <boost_at_[hidden]>
>Sent: Monday, May 07, 2001 4:55 PM
>Subject: [boost] Re: about function.hpp
>
>> Sure, you return a cookie used to identify the timer. But if you make
>> the reasonable requirement that you can't install multiple timers
>> on one callback you can ditch the cookie. I don't think it buys you
>> anything: it's just one more piece of data for users to juggle.
>> Whereas with my approach you can create a new callback whenever you
>> need to interact with the timer.
>
>In the specific case of timers, you probably want a class to manage the
>lifetime of a timer:
>
>class Timer {
> Timer(const function<void>& g, int ms) : f(g) { whatever.add_timer(f,
>ms); }
> ~Timer() { whatever.remove_timer(f); }
>private:
> boost::function<void> f;
>};
>
>Without such a class, your code is either not exception safe, or exceedingly
>difficult to read/maintain, or both. Given the necessity of such a class,
>it doesn't really matter if the underlying mechanism uses cookies or not.

You seem to be talking about the RAII idiom which doesn't seem to
really make sense for timers. Neither the Mac (with Carbon Event
timers) nor Windows (with WM_TIMER) are going to support creating a
timer on the stack inside a function which is where RAII shines. Not
that trying to do that makes any sense to me...

   -- Jesse


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk