Re: [Libevent-users] C++ interface(s) [was: libev-1.3e...]
On Sun, Nov 11, 2007 at 08:04:10PM +0100, Chris Brody <[EMAIL PROTECTED]> wrote: > 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 Thanks a lot (I really never tested with EV_MULTIPLICITY, so I am pleasently surprised you even got some results... :) > an ev_loop() function call. In addition, the EV_P (and EV_P_) macros > require the user code to use "using namespace ev"... user code should not need to use those macros... when does the need come up? (in fact, there should not be any macros defined, but I guess thats not reasonable, so maybe in the long run ev will have to end up in the std namespace) > 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. Ok, I wonder wether ev++ counts as heavily templated or not :) > 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! -- 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
Re: [Libevent-users] C++ interface(s) [was: libev-1.3e...]
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_) 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
Re: [Libevent-users] C++ interface(s) [was: libev-1.3e...]
[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_) 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
Re: [Libevent-users] C++ interface(s) [was: libev-1.3e...]
On 11/9/07, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Fri, Nov 09, 2007 at 01:28:08AM +0100, Chris Brody-GMail <[EMAIL > PROTECTED]> wrote: > > Your new archive built OK on my OSX machine-thanks again! > > Great. I am about to check in a change that allwos you to override header > locations e.g. like this: > > #define EV_H > #include "ev.c" > #define EV_EVENT_H > #include "event.c" First a quick remark: I thought these definitions were ugly. Another workaround on OSX would be to install ev.h in /usr/local/include since Apple's ev.h is in /usr/include. I would propose something like putting the definitions & macros in one file such as ev_defs.h, the function prototypes in ev_proto(types).h, and a convenience ev.h to include both. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] C++ interface(s) [was: libev-1.3e...]
On Fri, Nov 09, 2007 at 01:28:08AM +0100, Chris Brody-GMail <[EMAIL PROTECTED]>
wrote:
> Your new archive built OK on my OSX machine-thanks again!
Great. I am about to check in a change that allwos you to override header
locations e.g. like this:
#define EV_H
#include "ev.c"
#define EV_EVENT_H
#include "event.c"
> > I also wondered about (optionally, when embedding, so not directly
> > relevant to eventxx) having a member pointer + object instead of a
> > callback when compiling libev as C++.
>
> I will need some time to think about a clear solution-should be
> possible with a "pure inline" wrapper class.
There are basically two options:
- when embedding (and only then) optionally allow use of c++ features, making
libev a full c++ library incompatible with the c interface.
this saves a pointer, thunking code, makes the code safer etc. but loses
c compatibility.
this is something I might likely go after for purely personal reasons - I
have a lot of c++ programs currently using iom.C which could be converted
to a libev c++ lib.
this would be done using real subclassing etc:
struct ev_io : ev_watcher_list {
...
start ()
stop ()
and would complement libev nicely as its quite object-oriented in design.
- take the c interface and adapt it, very rough proof of concept:
namespace ev {
#include
extern "C" void thunk_io_cb (struct ev_io *w, int revents)
{
static_cast(w)->(revents);
}
template
struct adaptor : callback {
adaptor ()
{
ev_watcher_init (static_cast this, thunk_io_cb);
}
void start () { start (static_cast this); }
...
};
struct io : ev_io, adaptor {
void set (int fd, int events) { ev_io_set (...); }
};
#undef ev_watcher_init /* dangerous in c++ */
...
};
/* I'll spare you the details of how callback<> is defined */
This would also allow a relatively natural usage, like:
ev::io w (fd, EV_READ);
w.start ();
etc.
--
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
