Cons:
Overuse of inlining can actually make programs slower. Depending on a function's size, inlining it can cause the code size
to increase or decrease. Inlining a very small accessor function will usually decrease code size while inlining a very large
function can dramatically increase code size. On modern processors smaller code usually runs faster due to better use of
the instruction cache.
Decision:
A decent rule of thumb is to not inline a function if it is more than 10 lines long. Beware of destructors, which are often
longer than they appear because of implicit member- and base-destructor calls!
Another useful rule of thumb: it's typically not cost effective to inline functions with loops or switch statements (unless, in
the common case, the loop or switch statement is never executed).
It is important to know that functions are not always inlined even if they are declared as such; for example, virtual and
recursive functions are not normally inlined. Usually recursive functions should not be inline. The main reason for making
a virtual function inline is to place its definition in the class, either for convenience or to document its behavior, e.g., for
accessors and mutators.
~ The -inl.h Files
You may use file names with a -inl.h suffix to define complex inline functions when needed.
The definition of an inline function needs to be in a header file, so that the compiler has the definition available for
inlining at the call sites. However, implementation code properly belongs in .cc files, and we do not like to have much
actual code in .h files unless there is a readability or performance advantage.
If an inline function definition is short, with very little, if any, logic in it, you should put the code in your .h file. For
example, accessors and mutators should certainly be inside a class definition. More complex inline functions may also be
put in a .h file for the convenience of the implementer and callers, though if this makes the .h file too unwieldy you can
instead put that code in a separate -inl.h file. This separates the implementation from the class definition, while still
allowing the implementation to be included where necessary.
Another use of -inl.h files is for definitions of function templates. This can be used to keep your template definitions
easy to read.
Do not forget that a -inl.h file requires a #define guard just like any other header file.
~ Function Parameter Ordering
When defining a function, parameter order is: inputs, then outputs.
Parameters to C/C++ functions are either input to the function, output from the function, or both. Input parameters are
usually values or const references, while output and input/output parameters will be non-const pointers. When ordering
function parameters, put all input-only parameters before any output parameters. In particular, do not add new
parameters to the end of the function just because they are new; place new input-only parameters before the output
parameters.
This is not a hard-and-fast rule. Parameters that are both input and output (often classes/structs) muddy the waters, and,
as always, consistency with related functions may require you to bend the rule.
~ Names and Order of Includes
Use standard order for readability and to avoid hidden dependencies: C library, C++ library, other libraries' .h, your
project's .h.
All of a project's header files should be listed as descendants of the project's source directory without use of UNIX
directory shortcuts . (the current directory) or .. (the parent directory). For example, google-awesome-
project/src/base/logging.h should be included as
#include "base/logging.h"
评论1
最新资源