New iteration over the ev++ improvement patch.

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


On Sun, Jan 20, 2008 at 04:51:02PM -0200, Leandro Lucarella <llucax at gmail.com> 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
case.

> 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_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list