New iteration over the ev++ improvement patch.

Marc Lehmann schmorp at schmorp.de
Tue Jan 22 12:40:41 CET 2008


On Mon, Jan 21, 2008 at 11:25:52PM -0200, Leandro Lucarella <llucax at gmail.com> 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
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list