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
