New iteration over the ev++ improvement patch.

Marc Lehmann schmorp at
Mon Jan 21 05:44:29 CET 2008

On Sun, Jan 20, 2008 at 04:51:02PM -0200, Leandro Lucarella <llucax at> wrote:
> >   static struct
> >   {
> >     operator loop_ref () { return ...; }
> >   } default_loop;
> > 
> > would be interesting to see what kinds of overhead this creates, if any.
> I don't think it's going to work. Even if that struct takes no space, you
> get a multiple definition error when linking multiple translation units.

That would be a major bug in the compiler and/or linker? I doubt you will
find a compiler that buggy nowadays.

> And then, it would be useful only for passing arround since to call any
> methods you'll have to do something like
> ev::loop_ref(ev::default_loop).method();

Let's wait for c++0x and lets overwrite the . operator then. Or override
the -> operator now:

  ev_io myio (ev::default_loop);
  myio.start (...);
  ev::default_loop->run ();

Looks fine and sensible to me.

I think I said before that value semantics is IMnsHO the wrong approach,
as it makes the user believe he passes around loops, which is not the

> But it would be so nice if we can sort out a way to use the default_loop
> as an object.

I think the above works.

> We should provide an initialization method for the default loop and make
> the default constructor a NOP though.

The problem with thta is that you have no control over construction order
and flags.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list