On Sat, Dec 22, 2007 at 08:28:50AM -0500, Jeff Squyres <[EMAIL PROTECTED]> 
wrote:
> 1. Only instantiate the have_monotonic variable #if EV_USE_MONOTONIC  
> (have_monotonic's usage seems to be protected by EV_USE_MONOTONIC)
> 
> 2. Only declare infy_fork() #if EV_USE_INOTIFY (infy_fork()'s  
> definition is surrounded by #if EV_USE_INOTIFY)

I think these changes increase maintainance burden too much without
providing any real benefit. Not having have_monotonic is an exceptional
case, and having to maintain #ifdef logic for it probably creates more
problems than it solves.

> static struct ev_loop *
> ev_default_loop (unsigned int flags) { ... }
> 
> Should that function be marked as inline?

No, because inline semantics are not portable at the moment (C99 vs. gcc),
so static is the closest equivalent.

> That might result in a slight speedup on some platforms if the function 
> is actually inlined.                                                    

Only if it wouldn't get inlined already, which it will be in most
cases. Have you actually looked? It would be interesting to know which
compiler doesn't inline it under whcih conditions (obviously, gcc without
optimisation won't).

> Additionally, it would remove a -Wall warning about ev_default_loop()  
> being defined but not used in files that don't call it.

Making the code unportable to silence an optional warning in a compiler is
not really sensible, IMnsHO.

In general, you should NOT optimise for warnings, often this will result
in buggy or unportable code, and in many cases in harder to maintain code.

libev has been checked for relevant compiler warnings (on the platforms
and with the compilers I use only of course).

> Same goes for ev_now() in the !EV_MULTIPLICITY case.

Same reasoning here.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      [EMAIL PROTECTED]
      -=====/_/_//_/\_,_/ /_/\_\

_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

Reply via email to