On Mon, Jan 21, 2008 at 11:25:52PM -0200, Leandro Lucarella <[EMAIL PROTECTED]> wrote: > Well, the compiler complained about changing the meaning of loop in the > context of the watcher's base class, but adding the namespace to the type > when declaring the loop variable did the trick. > > I'll commit this patch unless you have something against it: > http://git.llucax.com.ar/?p=software/libev.git;a=commitdiff;h=a11114f6c6a06077bcd9e208c064ebed9e577f8c > > (I added operator () as an alias to run ()).
Looks fine, but please do not use EV_THROW for the exception specification (I changed thta in CVS already), but instead use plain throw (). The main drawback of using exceptions is using stdexcept, not specifying what a function throws. > > I don't find anything natural at all at calling as do-called "init" method > > in C++, "shouldn't this be done by the constructor?" :) > > Yes, but you didn't like the explicit default_loop instantiation =) > And the loop has to be initialized somewhere... Yes, when first accessed, e.g. here: ev::io myw(ev::default_loop); would be fine. My proposal does just that without static initialisation. > > In any case, I leave the final decision on how to implement this up to you > > :) > > For the sake of simplicity I think I'll go with the global function > returning a loop_ref. It's the closest to C API so if someone don't like > it I can blame you =P Given that I proposed a global variable without automatic intiialisation, I will promptly point back at you :) > Seriously, I see 2 main use cases: > 1) Use the default_loop just once, like the unloop() call in a callback. > 2) Use the default_loop more often. > > In case 1), the extra () is not such a big deal. In case 2), you'll > probably store the loop in a local variable for convenience (and/or > performance), so no problem there. > > If that's ok with you, I'll apply this patch to CVS too: > http://git.llucax.com.ar/?p=software/libev.git;a=commitdiff;h=cb6fa5ebc2f52e7224708fecf85032342d8ebeb8 I am ok with that in any case, I sodner you the principal architect of the c++ interface :) In any case, I don't see anythign wrong with providing mere function wrappers for the ev namespace, as the goal should be to take the C api and c++-ise it a bit, so if there is no obvious problem with using the c api approach, sounds perfetc to me :) -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
