[Libevent-users] Re: ev++.h issue with EV_MULTIPLICITY?

[Chris Brody]

On 11/14/07, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Tue, Nov 13, 2007 at 02:09:58AM +0100, Chris Brody <chris.brody at gmail.com> 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;