Re: New iteration over the ev++ improvement patch.
On Mon, Jan 21, 2008 at 11:25:52PM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: Well, the compiler complained about changing the meaning of loop in the context of the watcher's base class, but adding the namespace to the type when declaring the loop variable did the trick. I'll commit this patch unless you have something against it: http://git.llucax.com.ar/?p=software/libev.git;a=commitdiff;h=a4f6c6a06077bcd9e208c064ebed9e577f8c (I added operator () as an alias to run ()). Looks fine, but please do not use EV_THROW for the exception specification (I changed thta in CVS already), but instead use plain throw (). The main drawback of using exceptions is using stdexcept, not specifying what a function throws. I don't find anything natural at all at calling as do-called init method in C++, shouldn't this be done by the constructor? :) Yes, but you didn't like the explicit default_loop instantiation =) And the loop has to be initialized somewhere... Yes, when first accessed, e.g. here: ev::io myw(ev::default_loop); would be fine. My proposal does just that without static initialisation. In any case, I leave the final decision on how to implement this up to you :) For the sake of simplicity I think I'll go with the global function returning a loop_ref. It's the closest to C API so if someone don't like it I can blame you =P Given that I proposed a global variable without automatic intiialisation, I will promptly point back at you :) Seriously, I see 2 main use cases: 1) Use the default_loop just once, like the unloop() call in a callback. 2) Use the default_loop more often. In case 1), the extra () is not such a big deal. In case 2), you'll probably store the loop in a local variable for convenience (and/or performance), so no problem there. If that's ok with you, I'll apply this patch to CVS too: http://git.llucax.com.ar/?p=software/libev.git;a=commitdiff;h=cb6fa5ebc2f52e7224708fecf85032342d8ebeb8 I am ok with that in any case, I sodner you the principal architect of the c++ interface :) In any case, I don't see anythign wrong with providing mere function wrappers for the ev namespace, as the goal should be to take the C api and c++-ise it a bit, so if there is no obvious problem with using the c api approach, sounds perfetc to me :) -- 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: New iteration over the ev++ improvement patch.
On Mon, Jan 21, 2008 at 10:26:54PM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: Because we cannot initialise that static variable, or the user again ahs to call a method, which brings us back to the beginning of havign a method that needs to be called. User will need to call a method/funtion always, Not with the solution I proposed, no? calling the constructor is less explicit, but you didn't like the explicit instantiation either. So I don't understand what's your idea. Giving the user a variable instead of having to call a method. Remember the reason for this static thingabob was to avoid having to call a method in the first place. I don't remember. I don't understand what you mean either :) Well, read back the e-mail thread then :) The starting point was that we would like to have a cariable instead of havign to call a function (a syntactical thing), and I provided a way to do that. The redeeming quality of that is that we could replace it by a variable at a later time. -- 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: New iteration over the ev++ improvement patch.
On Tue, Jan 22, 2008 at 03:31:12PM -0200, Leandro Lucarella [EMAIL PROTECTED] wrote: The main drawback of using exceptions is using stdexcept, not specifying what a function throws. Well, I think you did a little more than what I expected. You made throwing bad_loop non-conditional. I think it make no sense to keep the conditional compilation just to set if std::runtime_error is used or not. Well, its the difference between rxvt-unicode compiling or not (it doesn't use the standard library), which I consider extremely crucial :) The main point of the conditional compilation were to avoid the overhead of exceptions, not the overhead of an (standard) include. What overhead of exceptions? Not calling throw doesn't, in general, avoid any overheads compilers add (and removing the throw specifications will, at best, introduce overheads because the compiler now has to deduce that no exceptions will be thrown (which is impossible in this case)). The runtime overhead is virtually nonexistant because you never really throw it except in, well, very exceptional conditions. -- 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: New iteration over the ev++ improvement patch.
Leandro Lucarella, el 21 de enero a las 11:30 me escribiste: Marc Lehmann, el 21 de enero a las 06:20 me escribiste: Let's wait for c++0x and lets overwrite the . operator then. Or override the - operator now: ev_io myio (ev::default_loop); myio.start (...); ev::default_loop-run (); It looks like you want me to rename loop() to run() =P Want is the wrong word, but it would enbale us to use struct loop in place of struct loop_ref. But it will forbids us to use the name loop for the watcher's variable. I don't think it does. At least my trivial testcase got the linking error with GCC. http://ue.tst.eu/3bb204f88a49475421615172f2ea7516.txt I would really be interested in your trivial case and the linking error you get. static variables *must* not collide, they are private to the translation unit. Ups! I didn't saw the magic word static :) I don't think it's that nice to compulsively add a variable to each translation unit, but since it doesn't take any space is not that bad. If we assume we can do that, why don't just making the old default_loop instantiated as a static global variable? That way is more straightforward. I've implemented that and it works (and looks, at least for me) just fine. Patch: http://git.llucax.com.ar/?p=software/libev.git;a=commitdiff;h=10971528d99cd30d0b09f7b44c434a15d6c4327c Example: http://git.llucax.com.ar/?p=software/libev.git;a=blob;f=test.cpp;h=d7c12e7c1ce33d426df6cba57d9ed571f53345bc;hb=2c1a7ea812881c88853408b5f248307922f66ac4 -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) - Los romanos no tenían paz, loco... Necesitaban un poco de chala... ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
