[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)
----------------------------------------------------------------------------
"CIRILO" Y "SIRACUSA" DE "SEÑORITA MAESTRA": UNO MUERTO Y OTRO PRESO
	-- Crónica TV




More information about the libev mailing list