[RFC] extending ev++.h to add C++ loop wrappers.

Leandro Lucarella llucax at gmail.com
Wed Jan 16 19:12:02 CET 2008

Marc Lehmann, el 16 de enero a las 05:43 me escribiste:
> > Second, I wrapped the loop not only for cosmetical purposes, I like the
> > automatic destruction =). If you lost the difference between an object and
> > a raw pointer, then you can't know when to call the ev_xxx_destroy()
> > (unless we use reference counting, which I think is overkill for this
> > case).
> You can have automatic destruction by providing three types:
>    ev::loop         // for storing loops
>    ev::loop_dynamic // for dynamically-created loops
>    ev::loop_default // for the default loop
> Naming could probbaly be improved, but you need these three types anyways,
> to be able to handle externally-provided loop pointers (which certainly
> will come up).

I'm trying to go back to this design, but I'm starting to need the loop to
be virtual again because, I can't put ev_xxx_destroy () call in the
destructor in the ev::loop (to follow the proposed names above).

Let me ilustrate with an example:

struct loop
	ev_loop *loop_;
	loop (ev_loop *l): loop_(l) {}
	// supposing this accepts the default loop too.
	~loop () { ev_loop_destroy(loop_); }
	// ... stuff

struct loop_dynamic: loop
	loop_dynamic (int flags): loop (ev_new_loop (flags)) {}

struct loop_default: loop
	loop_default (int flags): loop (ev_default_loop (flags)) {}

struct base
	ev_loop * loop;
	base(ev_loop *l): loop(l) { ... }

void cb(io &w, int revents)
	// I want to use the loop as an object
	loop l (w.loop); // fine
	l.unloop ();
	// woops! l.~loop() get's called and my loop is gone!

if ~loop () is empty and each destructor has it own ev_xxx_destroy ()
call, then when using a loop pointer, you can't destroy the loop
because of the lack of virtualness:

void bye(loop *l)
	delete l; // no ev_loop_destroy () is called

Maybe there's not much use for something that needs to treat a loop and a
default loop the same (like a container) since they are completely
different beasts, but the problem is still there.

Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
	-- Crónica TV

More information about the libev mailing list