Стандарт C++ 98, страница 3

Implementations are required to diagnose programsthat use such extensions that are ill-formed according to this International Standard. Having done so, however, they can compile and execute such programs.__________________3) “Correct execution” can include undefined behavior, depending on the data being processed; see 1.3 and 1.9.3ISO/IEC 14882:1998(E)© ISO/IEC1.5 Structure of this International Standard1.5 Structure of this International Standard1 General[intro.structure]1Clauses 2 through 16 describe the C++ programming language. That description includes detailed syntacticspecifications in a form described in 1.6. For convenience, Annex A repeats all such syntactic specifications.2Clauses 17 through 27 (the library clauses) describe the Standard C++ library, which provides definitionsfor the following kinds of entities: macros (16.3), values (clause 3), types (8.1, 8.3), templates (clause 14),classes (clause 9), functions (8.3.5), and objects (clause 7).3Annex B recommends lower bounds on the capacity of conforming implementations.4Annex C summarizes the evolution of C++ since its first published description, and explains in detail thedifferences between C++ and C.

Certain features of C++ exist solely for compatibility purposes; Annex Ddescribes those features.5Finally, Annex E says what characters are valid in universal-character names in C++ identifiers (2.10).6Throughout this International Standard, each example is introduced by “[Example:” and terminated by “]”.Each note is introduced by “[Note:” and terminated by “]”. Examples and notes may be nested.1.6 Syntax notation1[syntax]In the syntax notation used in this International Standard, syntactic categories are indicated by italic type,and literal words and characters in constant width type.

Alternatives are listed on separate linesexcept in a few cases where a long set of alternatives is presented on one line, marked by the phrase “oneof.” An optional terminal or nonterminal symbol is indicated by the subscript “opt,” so{ expressionopt }indicates an optional expression enclosed in braces.2Names for syntactic categories have generally been chosen according to the following rules:— X-name is a use of an identifier in a context that determines its meaning (e.g. class-name, typedefname).— X-id is an identifier with no context-dependent meaning (e.g. qualified-id).— X-seq is one or more X’s without intervening delimiters (e.g. declaration-seq is a sequence of declarations).— X-list is one or more X’s separated by intervening commas (e.g.

expression-list is a sequence of expressions separated by commas).1.7 The C++ memory model[intro.memory]1The fundamental storage unit in the C++ memory model is the byte. A byte is at least large enough to contain any member of the basic execution character set and is composed of a contiguous sequence of bits, thenumber of which is implementation-defined. The least significant bit is called the low-order bit; the mostsignificant bit is called the high-order bit.

The memory available to a C++ program consists of one or moresequences of contiguous bytes. Every byte has a unique address.2[Note: the representation of types is described in 3.9. ]1.8 The C++ object model1[intro.object]The constructs in a C++ program create, destroy, refer to, access, and manipulate objects.

An object is aregion of storage. [Note: A function is not an object, regardless of whether or not it occupies storage in theway that objects do. ] An object is created by a definition (3.1), by a new-expression (5.3.4) or by theimplementation (12.2) when needed.

The properties of an object are determined when the object is created.An object can have a name (clause 3). An object has a storage duration (3.7) which influences its lifetime(3.8). An object has a type (3.9). The term object type refers to the type with which the object is created.4© ISO/IECISO/IEC 14882:1998(E)1 General1.8 The C++ object modelSome objects are polymorphic (10.3); the implementation generates information associated with each suchobject that makes it possible to determine that object’s type during program execution. For other objects,the interpretation of the values found therein is determined by the type of the expressions (clause 5) used toaccess them.2Objects can contain other objects, called sub-objects.

A sub-object can be a member sub-object (9.2), abase class sub-object (clause 10), or an array element. An object that is not a sub-object of any other objectis called a complete object.3For every object x, there is some object called the complete object of x, determined as follows:— If x is a complete object, then x is the complete object of x.— Otherwise, the complete object of x is the complete object of the (unique) object that contains x.4If a complete object, a data member (9.2), or an array element is of class type, its type is considered themost derived class, to distinguish it from the class type of any base class subobject; an object of a mostderived class type is called a most derived object.5Unless it is a bit-field (9.6), a most derived object shall have a non-zero size and shall occupy one or morebytes of storage.

Base class sub-objects may have zero size. An object of POD4) type (3.9) shall occupycontiguous bytes of storage.6[Note: C++ provides a variety of built-in types and several ways of composing new types from existingtypes (3.9). ]1.9 Program execution[intro.execution]1The semantic descriptions in this International Standard define a parameterized nondeterministic abstractmachine. This International Standard places no requirement on the structure of conforming implementations. In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming implementations are required to emulate (only) the observable behavior of the abstract machine asexplained below.5)2Certain aspects and operations of the abstract machine are described in this International Standard asimplementation-defined (for example, sizeof(int)).

These constitute the parameters of the abstractmachine. Each implementation shall include documentation describing its characteristics and behavior inthese respects. Such documentation shall define the instance of the abstract machine that corresponds tothat implementation (referred to as the ‘‘corresponding instance’’ below).3Certain other aspects and operations of the abstract machine are described in this International Standard asunspecified (for example, order of evaluation of arguments to a function).

Where possible, this International Standard defines a set of allowable behaviors. These define the nondeterministic aspects of theabstract machine. An instance of the abstract machine can thus have more than one possible executionsequence for a given program and a given input.4Certain other operations are described in this International Standard as undefined (for example, the effect ofdereferencing the null pointer). [Note: this International Standard imposes no requirements on the behaviorof programs that contain undefined behavior. ]5A conforming implementation executing a well-formed program shall produce the same observable behavior as one of the possible execution sequences of the corresponding instance of the abstract machine withthe same program and the same input.

However, if any such execution sequence contains an undefinedoperation, this International Standard places no requirement on the implementation executing that program__________________4) The acronym POD stands for “plain old data.”5) This provision is sometimes called the “as-if” rule, because an implementation is free to disregard any requirement of this International Standard as long as the result is as if the requirement had been obeyed, as far as can be determined from the observable behaviorof the program.

For instance, an actual implementation need not evaluate part of an expression if it can deduce that its value is not usedand that no side effects affecting the observable behavior of the program are produced.5ISO/IEC 14882:1998(E)1.9 Program execution© ISO/IEC1 Generalwith that input (not even with regard to operations preceding the first undefined operation).6The observable behavior of the abstract machine is its sequence of reads and writes to volatile data andcalls to library I/O functions.6)7Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/Ofunction, or calling a function that does any of those operations are all side effects, which are changes in thestate of the execution environment. Evaluation of an expression might produce side effects.

At certainspecified points in the execution sequence called sequence points, all side effects of previous evaluationsshall be complete and no side effects of subsequent evaluations shall have taken place.7)8Once the execution of a function begins, no expressions from the calling function are evaluated until execution of the called function has completed.8)9When the processing of the abstract machine is interrupted by receipt of a signal, the values of objects withtype other than volatile sig_atomic_t are unspecified, and the value of any object not ofvolatile sig_atomic_t that is modified by the handler becomes undefined.10An instance of each object with automatic storage duration (3.7.2) is associated with each entry into itsblock.