On Sun, Jan 20, 2008 at 04:51:02PM -0200, Leandro Lucarella <[EMAIL PROTECTED]> 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 --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev