Marc Lehmann, el 18 de enero a las 06:08 me escribiste: > On Thu, Jan 17, 2008 at 05:08:16PM -0200, Leandro Lucarella <[EMAIL > PROTECTED]> wrote: > > Well, after all the talking and thinking, this is what I came up with. > > > > Main changes: > > * The use of exceptions is now optional (configurable via > > EV_CXX_EXCEPTIONS). I don't know if: > > #define throw(exception) throw (exception) > > is valid preprocesor code though =) > > the "recursion" is fine, overriding throw isn't, because: > > a) you sometimes use a zero-argument form of throw()
Not in ev++.h and throw is #undef'ed when the file ends. > b) overriding throw isn't really legal Where did you found that? > c) never override stuff the uer validly might have overridden herself already This goes against b), but well, is a valid argument. =) > > - No check is done when creating a default_loop to see if one is already > > created (could be trouble if ev_default_destroy() is called more than > > once?). > > right now, calling ev_default_destroy twice is a bug. this is safe, however: > > ev_default_init (0); ev_default_destroy () Ugly hack, but clever =P > I think at first we should do it that way, we can simplify later, > together with changing ev_default_* into aliases to the ev_loop functions > internally. Ok. > > * A new function ev::get_default_loop () is provided to get a loop_ref to > > the default loop. Once again, no check is done to ensure this function > > wont get called before actually creating the default loop. > > Can't help it, I still am not sure we should provide an actual default > loop wrapper, as I think the default loop is a shared resource that is not > controlled by any one instance. In this scheme, the lifetime is controlled by an instance. But I think default_loop struct could be gone (and get_default_loop () renamed to default_loop () to mimic the C interface, but getting a loop_ref instead of a ev_loop*). I like the instance-way though. > > * loop_ref::fork() is now named loop_ref::fix_fork(). > > try post_fork, it doesn't really fix any fork thing :) Ok, so you had a suggestion after all ;) > > * ev::time() is now named ev::now(). > > bad idea, now "now" means something for C, and something else for > C++. I would expect ev::now() to do mostly the same as ev_now (). As you said, I think ev_time should be ev_now and ev_now should be ev_loop_now. This could start the path to move that way. > > * ev::sleep() is now named ev::delay() (stolen from SDL ;). > > ah well :) > > I wonder wether we shouldn't use some prefix instead instead of renaming > all symbols. I don't really like prefixes, I prefer renaming in this case. At least could you consider just an underscore? sleep_, fork_, time_? I know you use that naming convention for "private" methods but is a used naming convention for variables with keyword names for example. I still prefer nice renamed names than straight ugly ones. For time, I think now () is the right name, and is the C API that should be fixed :), for fork () I think post_fork () is right too, because if you aren't fixing anything, you are not forking anything either, and delay () it's not such a bad name. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- ADOLESCENTE MUERE DESNUCADO POR TRATAR DE AUTOCHUPARSE -- Cronista TV _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
