On 11/14/07, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 02:09:58AM +0100, Chris Brody <[EMAIL PROTECTED]> > wrote: > > I've been trying the same test program with and without > > EV_MULTIPLICITY=1. This program compiles and runs properly with > > EV_MULTIPLICITY=0, but does not build if EV_MULTIPLICITY=1. I am > > getting the following error: > > Yeah, of course, we are fighting an uphill battle: I don't use multiplicity > anywhere, and its nevertheless the default mode *g* I had another idea, for your automake to generate both "normal" (default EV_MULTIPLICITY=1) versions of the ev(ent) libraries and EV_MULTIPLICITY=0 versions of the ev(ent) libraries.
In addition, if the evbuffer part were also in a separate library from the ev(ent) library/ies, then we would have fewer library versions to manage... > Thanks for the test program! I believe credit belongs to the authors of both the eventxx & libevent projects... > For multiplicity and C++, I chose to have the same prototype, excluding > the loop, because the loop is already stored in the watcher that is being > passed. > > As such, this is the correct prototype: > > void meth (ev::sig &w, int ) > > This also relieves you from having to store the loop, you could simply > take it from the watcher: > > ev::ev_unloop(l, EVUNLOOP_ONE); > => > ev::ev_unloop(w.loop, EVUNLOOP_ONE); Yes! > (You could convince me to include it, but since the current ev++.h > practically enforces a strong marriage between watcher and loop, this > seems excessive. Its a trade-off between similarity to C and C++-ness). No. I had yet another idea, to allow someone to declare a "classical" C-callback, just like you find in event.h and eventxx. I think this would make it much quicker use ev++ in an existing libevent-based application without the event.h layer. Perhaps in subclass(es)... I can propose a patch. > Here is your test program modified to do the expected thing (guessing what > expected is ... :) > > http://data.plan9.de/y.C I just built with and without EV_MULTIPLICITY=0 on Linux (64) and ran with success. Now that the callback has been fixed, we can fix the namespace by two options, both tested with & without EV_MULTIPLICITY=0: Option 1: $ diff -u y.C y1.C --- y.C 2007-11-14 12:48:52.000000000 +0100 +++ y1.C 2007-11-14 13:05:38.000000000 +0100 @@ -3,10 +3,6 @@ #include "ev++.h" -#if EV_MULTIPLICITY -using namespace ev; -#endif - struct handler { int i; Option 2: $ diff -u y.C y2.C --- y.C 2007-11-14 12:48:52.000000000 +0100 +++ y2.C 2007-11-14 13:04:13.000000000 +0100 @@ -3,9 +3,7 @@ #include "ev++.h" -#if EV_MULTIPLICITY using namespace ev; -#endif struct handler { @@ -13,7 +11,7 @@ handler(): i(0) {} - void meth (ev::sig &w, int ) + void meth (sig &w, int ) { std::cout << ++i << " interrupts, "; if (i < 5) std::cout << "keep going...\n"; @@ -22,9 +20,9 @@ std::cout << "done!\n"; #if EV_MULTIPLICITY - ev::ev_unloop(w.loop, EVUNLOOP_ONE); + ev_unloop(w.loop, EVUNLOOP_ONE); #else - ev::ev_unloop(EVUNLOOP_ONE); + ev_unloop(EVUNLOOP_ONE); #endif } } @@ -32,17 +30,17 @@ int main() { - ev::ev_default_loop(EVFLAG_AUTO); + ev_default_loop(EVFLAG_AUTO); handler h; - ev::sig mysig(&h, &handler::meth); + sig mysig(&h, &handler::meth); mysig.start(SIGINT); #if EV_MULTIPLICITY - ev::ev_loop(ev::ev_default_loop(0), 0); + ev_loop(ev_default_loop(0), 0); #else - ev::ev_loop(0); + ev_loop(0); #endif return 0; _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
