David Megginson writes:
>
> Without
>inlined methods, we'll probably end up with a smaller fgfs executable,
>more accurate debugging information, faster build times, and more
>readable headers, etc.
>
>If we default to out-of-line code, then we can profile later and
>inline only in the spots where it actually helps.

In general I think that this is a good policy however
IMHO Simon Fowler posted a gem :-)

"""
The first patch should be against Documentation/CodingStyle.
What are we trying to achieve here?  What are the guidelines
for when-to and when-to-not?  I'd say:

- If a function has a single call site and is static then it
  is always correct to inline.

- If a function is very small (20-30 bytes) then inlining
  is correct even if it has many call sites.

- If a function is less-small, and has only one or two
  *commonly called* call sites, then inlining is OK.

- If a function is a leaf function, then it is more inlinable
  than a function which makes another function call.

=== added by NHV ===
Otherwise leave it a normal function call ! 
"""

Also note that most FGFS functions are only called once
or twice per iteration of the main loop

A 'few' more 'interesting' ones are called MANY TIMES 
per iteration of the loop.  IMHO these if they meet the 
above criteria are 'candidates' for inline-ing

Cheers

Norman

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to