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

Marc Lehmann schmorp at schmorp.de
Fri Jan 18 06:20:12 CET 2008

On Thu, Jan 17, 2008 at 10:28:16AM -0200, Leandro Lucarella <llucax at gmail.com> wrote:
> > Bause I don't: I changed ->stat to ->update already and it sucks. The
> > obvious method would be to call them ev_sleep etc. (haha).
> do_/get_xxx? do_fork, do_sleep, get_time?
> fix_fork? go_sleep? now? (note that the now that gets the loop time is in
> the loop object in ev:: =)

I frankly don't know.

(as for now, I think then libev should have ev_now => ev_time, and ev_now
=> ev_loop_now, but thats ugly).

The prefix method, however ugly, is at leats consistent between C and C++.

But of course do_ is about the worst possible prefix. I can't come up with
anything better, sorry.

I guess the total rename is mostly the way to go then, i.e. deviate as
much as neccessary from the C API.

> > Another option would be to #undef sleep in the header file. Thats rather
> > drastic however and some people will hate us for it.
> Yeah, I think that would be pretty hardcore...

Says the guy who redefined throw().

On Thu, Jan 17, 2008 at 10:46:52AM -0200, Leandro Lucarella <llucax at gmail.com> wrote:
> > That is pretty dumb to begin with.
> No, the problem is, for example:
> void cb (ev::io &w, int revents)
> {
> 	w.loop->unloop();
> 	delete w.loop;
> }

Thats pretty dumb to begin with, yes: deleting a loop that is actively
running in ev_loop *is* pretty dumb, and undefined behaviour will be the

> This would be strange anyways, because you probably will know beforehand
> that *that* loop is really a dynamic or default loop.

Not just that, you are likely executing the callback form within ev_loop,
and freeing its memory while its still bein accessed is not going to work,

> OTOH if w.lopp is a loop_ref instead of a ev_loop*, you can't even do the
> delete w.loop because it's a value type. You should do something like
> w.loop.destroy (), but that destroy have to be virtual, unless
> ev_loop_destroy () can destroy both type of loops (which I think I could
> be nice and avoid some problems).

I think onyl the default destructor should destroy the loop. That practically
ensures that it works (and you already implemneted it that way :)

> Can I rely on ev_loop_{fork,destroy} accepting default loops when

Definitely not, we should work aroundt hat way, even if inefficient, at the
moment, and later redesign those functions and optimise the ev++.h use.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list