Data Representation

Rec. 77.Do not assume that you know how an instance of a data type is represented in memory.

Rec. 78.Do not assume that data of a given size may begin at an arbitrary address.

The representation of data types in memory is highly machine-dependent. By allocating data members to certain addresses, a processor may execute code more efficiently. Because of this, the data structure that represents a class will sometime include holes and be stored differently in different process architectures. Code that depends on a specific representation is, of course, not portable.

See Type Conversionsfor explanation ofRec. 78.

Underflow/Overflow

Rec.79.Do not depend on underflow or overflow functioning in any special way.

Order of Execution

Rule 61.Do not assume that the operands in an expression are evaluated in a definite order.

Rule 62.Do not assume that you know how the invocation mechanism for a function is implemented.

Rule 63.Do not assume that an object is initialized in any special order in constructors.

Rule 64.Do not assume that static objects are initialized in any special order.

Certain expressions are ambiguous in their meaning. These expressions occur most frequently when an object's value is modified more than once in the same expression. These expressions rely on a particular order of evaluation where the language does not define one. See Example 70.

The order in which the member initializers are specified in the constructor does not affect the order in which the members are constructed (see Example 71). For example, in MS Visual C++ the members are constructed in the order in which they are declared in the class.

The order of initialization for static objects may present problems. A static object may not be used in a constructor, if it is not initialized until after the constructor is run. For static objects declared in different compilation units the order of initialization is not defined. This can lead to errors that are difficult to locate (see Example 72). There are special techniques for avoiding this (seeExample 33).

Temporary Objects

Rec. 80.Do not write code that depends on the lifetime of a temporary object.

Temporary objects are often created in C++. For example, a temporary will be created to store the return value of a function that returns a user-defined type if the return value is not copied to another object.

Difficult errors may arise when there are pointers to temporary objects. Since the language does not define the life expectancy of temporary objects, it is never certain that their pointers are valid when they are used. See Example 73.

One way of avoiding this problem is to make sure that temporary objects are not created. This method, however, is limited by the expressive power of the language and is not generally recommended.

Pointer Arithmetic

Rule 65.Do not use pointer arithmetic.

Rec. 81.Avoid using shift operations instead of arithmetic operations.

Pointer arithmetic can be portable. The operators ==and!=are defined for all pointers of the same type, while the use of the operators<,>,<=, and=>are portable only if they are used between pointers that point into the same array.