Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
CQG / Задание1 / HDS_VCPP_Programming Rules.doc
327.68 Кб

Inline Functions

Rec. 46.Do not use the preprocessor directive#defineto obtain code that is more efficient; use inline functions instead.

Rec. 47.Use inline functions when they are really needed.

See also Inline FunctionsinClasses andExample 43.

Inline functions have the advantage of often being faster to execute than ordinary functions. On the other hand, the implementation of an inline function must be placed in an include file, while the implementation of an ordinary function may be placed in its own separate file. Therefore, the implementation becomes more exposed. In addition, a change in the implementation of an inline function can require comprehensive re-compiling when the include file is changed.

The compiler is not compelled to actually make a function inline. The decision criteria for this differ from one compiler to another. It is often possible to set a compiler flag so that the compiler gives a warning each time it does not make a function inline (contrary to the declaration). “Outlined inlines” can result in programs that are both unnecessarily large and slow.

Temporary Objects

Rec. 48.Minimize the number of temporary objects that are created as return values from functions or as arguments to functions.

Temporary objects are often created when objects are returned from functions or when objects are given as arguments to functions. In either case, a constructor for the object is first invoked; later, a destructor is invoked. Large temporary objects make code inefficient. See Example 44.

In some cases, errors are introduced when temporary objects are created. It is important to keep this in mind when writing code. It is especially inappropriate to have pointers to temporary objects, since the lifetime of a temporary object is undefined. See Temporary ObjectsinPortable Code.


Rec. 49.Avoid long and complex functions.

Long functions have disadvantages:

  • If a function is too long, your function users can hardly understand it. Generally, it can be said that a function should not be longer than two pages, since that is about how much it can be realized at one time.

  • An error situation can be discovered at the very end of an extremely long function. It may be then difficult for the function to clean up after itself and to “undo” as much as possible before reporting the error. By always using short functions, such an error can be more exactly localized.

Complex functions are difficult to test. If a function consists of 15 nested ifstatements, then there are 2**15 (or 32768) different branches to test in a single function.


Rec. 50.Avoid the use of numeric values in code; use symbolic values instead.

Rec. 51.Constants should be defined usingconstorenum, avoid using#define.

Numerical values in code (“Magic Numbers”) should be viewed with suspicion. They can be the cause of difficult problems when it becomes necessary to change a value. A large amount of code can depend on such a value. Since the value can be used at a number of places in the code, it may be difficult to locate all of them. Moreover, such values are rather anonymous (it may be that not every 2in the code should be changed to a3).

From the point of view of portability, absolute values may be the cause of more subtle problems. The type of a numeric value is dependent on the implementation. Normally, the type of a numeric value is defined as the smallest type that can contain the value.

However, certain numerical values have a well-established and clear meaning in a program. For example, 0is often used in equality operations. Those values may be used directly in code without being considered as “Magic”.

The preprocessor performs a textual substitution for macros in the source code that is then compiled. This has a number of negative consequences. For example, if a constant has been defined using #define, the name of the constant is not recognized in many debuggers. If the constant is represented by an expression, this expression may be evaluated differently for different instantiations, depending on the scope of the name. In addition, macros are often incorrectly written.

See Examples 45and46.