Hi Marc,
I went through the libev++.h and managed to re-hack the
functor-way.cpp signal test for libev++.
My first comment is that building with EV_MULTIPLICITY=1 (the default
value) caused a few problems since there is both a struct ev_loop and
an ev_loop() function call. In addition, the EV_P (and EV_P_) macros
require the user code to use "using namespace ev"...
I am using the CINT C++ interpreter for my personal project, which
does exhibit a few quirks. For any C++ class that is called by
interpreted code, CINT has to parse the header file and make a dynamic
library that is called in reaction to interpreted C/C++ code. It is
only "85%" compliant and has real trouble with significantly templated
code.
But if I make a C++ subclass (or several C++ subclasses) that are less
complex, these should be more straightforward to be used dynamically.
I will try this and provide some more feedback.
Thanks,
Chris
On Nov 11, 2007 4:32 AM, Marc Lehmann <[EMAIL PROTECTED]> wrote:
> [note that i replied to the list, I hope this was ok, as I think a c++
> interface *might* interest other users too. If anybody finds it too
> off-topic, tell me and I will repent :]
>
> On Fri, Nov 09, 2007 at 07:32:13PM +0100, Chris Brody <[EMAIL PROTECTED]>
> wrote:
> > > start ()
> > > stop ()
> > >
> > > and would complement libev nicely as its quite object-oriented in design.
> > Yes-I definitely like this idea, with such an immediate re-use for a
> > wide-spread application.
>
> I tried it, but found it was quite the nuisance and made the header file
> rather ugly.
>
> Since I am in immediate porting needs to replace my older iom.C solution in
> gvpe and urxvt, I started a c++ interface.
>
> It is very similar to iom.C (and also very similar to libev, of course),
> but provides a bit more fluffyness (you can call ->set anytime and it will
> automatically stop/restart the event watcher).
>
> Its currently only useful for embedding (its in the files ev++.h and
> ev++.C), but I didn't chose to override the callback proper, so one can mix C
> users of libev and c++ users of the same.
>
> > I am thinking about how to make some kind of "thunk" callback
> > connector to go directly between libev and eventxx.
>
> This is what ev++.h also does, to keep full ABI compatibility. ev++.h is
> currently more or less providing simple wrappers around the watchers allowing
> object methods as callbacks.
>
> What is missing would be a nicer namespace cleanup (wrapper functions so
> ev_xxx becomes ev::xxx not ev::ev_xxxx) and a nice event loop and default
> loop abstraction.
>
> (I will probbaly switch to using enums for constants in ev.h at one point,
> although this is not quite as helpful as one would assume :)
>
> > If you do make this one, I will also consider how to use it with eventxx.
>
> Not having analyzed eventxx in detail, I believe the interfaces to be
> quite different in style, with ev++ being quite a bit more primitive
> (except in its callback system which is more complex).
>
> Here is an example use (more or less straight from rxvt-unicode):
>
> struct term {
> void cursor_blink_cb (ev::timer &w, int revents); ev::timer
> cursor_blink_ev;
> ...
> };
>
> term::term ()
> : cursor_blink_ev (this, &term::cursor_blink_cb)
> {
> ...
>
> if (option (Opt_cursorBlink))
> cursor_blink_ev.start (CURSOR_BLINK_INTERVAL, CURSOR_BLINK_INTERVAL);
> }
>
> void
> rxvt_term::cursor_blink_cb (ev::timer &w, int revents)
> {
> hidden_cursor = !hidden_cursor;
> want_refresh = 1;
> }
>
> As you can see, there are aliases for start that also set the time - I did
> this because I had lots of code using the convention, and it doesn't seem to
> hurt the interface.
>
> For multiple event loops (not really tested), the constructor has an
> additional argument for the event loop to associate with (using the
> default event loop if not given), and also has a set method that changes
> association.
>
> This is neccessary because I decided that the destructor has to call
> stop(), which requires storing the event loop inside the watcher
> somewhere.
>
> Anyways, this is just a start to convert my existing projects, but it
> seems to work quite well.
>
>
> --
> The choice of a Deliantra, the free code+content MORPG
> -----==- _GNU_ http://www.deliantra.net
> ----==-- _ generation
> ---==---(_)__ __ ____ __ Marc Lehmann
> --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
> -=====/_/_//_/\_,_/ /_/\_\
>
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
