Re: [RFC] extending ev++.h to add C++ loop wrappers.
On Wed, Jan 16, 2008 at 03:37:12PM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: Well, I think its a wonderful idea, its a loop, it should be called loop :) If we call it loop, then the loop() method has to be called other way, that's why I didn't call it loop. Maybe loop - start, unloop - stop (like watchers? but since they are radically different methods, maybe the must be called otherwise). Maybe just loop - do_loop? loop::run () // flags=0 loop::one_iteration () // once loop::sweep () // nonblock would be possible :) Or even: loop (); :- the reason it is called ev_loop is caused by a limitation in C's object orientation, and I think we can get away with renaming it here (it actually is taken mostly from libevent, and today I think maybe its not that good an interface). I am not saying we should rename it, its basically the question wether we want to use something ugly like loop_ref and a loop_ref::loop, or a loop, and a renamed (nut nice) loop::run (). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [RFC] extending ev++.h to add C++ loop wrappers.
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
___
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [RFC] extending ev++.h to add C++ loop wrappers.
Leandro Lucarella, el 16 de enero a las 15:37 me escribiste: Marc Lehmann, el 16 de enero a las 05:43 me escribiste: Maybe loop_simpel should rarlly be loop if we can get away with it without collisions. Yes, I thought about it too, but with all that loop everywhere I didn't thought it was a great idea (exactly because the high probability of colission ;). But once the patch is stabilized I can try to rename it to loop and see what happens... Well, I think its a wonderful idea, its a loop, it should be called loop :) If we call it loop, then the loop() method has to be called other way, that's why I didn't call it loop. Maybe loop - start, unloop - stop (like watchers? but since they are radically different methods, maybe the must be called otherwise). Maybe just loop - do_loop? Even more, if we call it loop, then we can't name the internal base watcher variable loop either :S -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) No es malo que en la condición humana exista la mentira. Miente el púber si quiere ponerla. -- Ricardo Vaporeso. Madrid, 1921. ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: [RFC] extending ev++.h to add C++ loop wrappers.
On Tue, Jan 15, 2008 at 11:34:41AM -0200, Leandro Lucarella [EMAIL PROTECTED]
wrote:
Hmm, the loops are not polymorphic, so the dynamic_cast will not be helpful.
In any case, is_default == (loop_ == ev_default_loop (0)).
They are in the patch I sent =)
Just for the fork() and destructors.
Oh, horrible. Would it be possible to get rid of that with an explicit
(non-dynamic-cast) is_default check?
In fact, I could document and commit to ev_loop_fork and ev_loop_destroy
working on the default loop as well (they don't at the moment, but its
easy to do that), so no polymorphism is needed and all the ideas about
loops being as efficient as ev_loop pointers would then become true :)
If everything *is* inside ev:: that would be fine, but its quite a bit of
work. Otherwise, I have no hard feelings either way.
Is not that hard, is a bit of work done once (and it's already done in the
patch ;). So, it's ok for you to expose the entire API in the ev namespace?
Absolutely.
If you could fine a nice way to hide it from the default namespace this would
be even better, but ev.h defines so many macros...
for various reasons, I would prefer the _ at the end, but again, I don't
care much :)
I'm use to the _ as a prefix, but I don't care much either and is you
lib, so, I'll use the suffix form ;)
Well, the reason is that that the _-namespace is not completely usable by
apps and it is easy to stumble over reserved namespace that way, which cannot
happen with a trailing _. It doesn't matter in that case, it just explains my
general prefernce to do it that way always.
I wonder why it cannot be simply loop? Does it collide with anything?
Yes, with loop_base loop().
How about get_loop? I am not being funny, because I would expect loop to
be either a mutator (which optionally sets it and this becoems equivalent
with a variable), or separate get/set methods.
In the end, I'd simply prefer it to be exposed, however, I am not a friend
of making getters and setters that are trivial (in my experience, either
you have a language that makes variabkles syntactically equivalent to
methods (self, javascript...) or you will not want to take the speed
hit of a nontrivial setter anyways and thus change caller code on any
changes).
I cna be convinced otherwise, though, these are just my thoughts.
But if you think is too much trouble, I cant expose the loop (without _)
pointer directly.
I am mostly fine with it, if I cannot convince you with my arguments
above, we will do it as you said.
That would only be true if fork can be a macro symbol. I don't know if
this is actually done by any OS but the POSIX standard don't say anything
about fork() being a macro (or even if it's implementation defined) [1] as
it does with other symbols (FD_XXX for instance [2]).
Ha! Quoting posix on me! :)
http://www.opengroup.org/onlinepubs/95399/functions/xsh_chap02_01.html
Any function declared in a header may also be implemented as a macro
defined in the header...
Maybe loop_simpel should rarlly be loop if we can get away with it
without collisions.
Yes, I thought about it too, but with all that loop everywhere I didn't
thought it was a great idea (exactly because the high probability of
colission ;). But once the patch is stabilized I can try to rename it to
loop and see what happens...
Well, I think its a wonderful idea, its a loop, it should be called loop :)
I dtetes loop_base, if we would need a seperate ype, it should probably be
loop_t (which is immensely ugly), so why not settle for class loop in
conflicts? :)
(See above for going with you if this isn't convincing)
+ inline
+ loop_default
+ default_loop (int flags)
+ {
+static loop_default l (flags);
+return l;
+ }
I my, I am scared at how horrible code that will generate in each
translation unit (I know, the same thing is done in ev.h, but its still
ugly :). Maybe leave it up to the user to declare her own loop_default
object? Or maybe not.
The problem with that is the lack of a standard mechanism to access to
that default loop (for instance, in the watchers contructors to use it as
a default argument).
Oh right, the default loop would detroy itself in the destructor. Maybe
we shouldn't do that (destroying the default loop, a singleton object, is
deeply anti-OO, maybe the right thing is to not do it?)
#if EV_MULTIPLICITY
- EV_P;
+ loop_base *_loop;
Thats the only negative thing, as it creates a need to use the ev++.h loop
wrappers.
And that is wrong because? I think if you are using ev++.h you'll be
glad to use the loop wrapper =)
Sure, but its less flexible, and breaks all my C++ code :)
If we could do both, that would certainly be better, no? :)
The problem is not uglier code in watchers. The problem is when you store
an ev_loop*, you can't get back the loop_xxx object (unless you use some
hash to access the object using the loop
