Стандарт C++ 11, страница 5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23456Directed acyclic graph . . . .Non-virtual base . . . . . . .Virtual base . . . . . . . . . .Virtual and non-virtual baseName lookup . . . . . . . . .7Stream position, offset, and size types [non-normative] . . . . . . . . . . . . . . . . . . . .

. . . . 989..............................................................................................................................................................................................78234235236236239List of Figures© ISO/IEC 2011 – All rights reservedxvISO/IEC 14882:2011(E)ForewordISO (the International Organization for Standardization) and IEC (the International ElectrotechnicalCommission) form the specialized system for worldwide standardization. National bodies that are members ofISO or IEC participate in the development of International Standards through technical committeesestablished by the respective organization to deal with particular fields of technical activity. ISO and IECtechnical committees collaborate in fields of mutual interest.

Other international organizations, governmentaland non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of informationtechnology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.The main task of the joint technical committee is to prepare International Standards. Draft InternationalStandards adopted by the joint technical committee are circulated to national bodies for voting.

Publication asan International Standard requires approval by at least 75 % of the national bodies casting a vote.Attention is drawn to the possibility that some of the elements of this document may be the subject of patentrights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.ISO/IEC 14882 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,Subcommittee SC 22, Programming languages, their environments and system software interfaces.This third edition cancels and replaces the second edition (ISO/IEC 14882:2003), which has been technicallyrevised.xvi© ISO/IEC 2011 – All rights reservedINTERNATIONAL STANDARD11.1ISO/IEC 14882:2011(E)General[intro]Scope[intro.scope]1This International Standard specifies requirements for implementations of the C++ programming language.The first such requirement is that they implement the language, and so this International Standard alsodefines C++.

Other requirements and relaxations of the first requirement appear at various places withinthis International Standard.2C++ is a general purpose programming language based on the C programming language as specified inISO/IEC 9899:1999, Programming languages — C (hereinafter referred to as the C standard). In addition tothe facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces,operator overloading, function name overloading, references, free store management operators, and additionallibrary facilities.1.21Normative references[intro.refs]The following referenced documents are indispensable for the application of this document.

For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document(including any amendments) applies.— Ecma International, ECMAScript Language Specification, Standard Ecma-262, third edition, 1999.— ISO/IEC 2382 (all parts), Information technology — Vocabulary— ISO/IEC 9899:1999, Programming languages — C— ISO/IEC 9899:1999/Cor.1:2001(E), Programming languages — C, Technical Corrigendum 1— ISO/IEC 9899:1999/Cor.2:2004(E), Programming languages — C, Technical Corrigendum 2— ISO/IEC 9899:1999/Cor.3:2007(E), Programming languages — C, Technical Corrigendum 3— ISO/IEC 9945:2003, Information technology — Portable Operating System Interface (POSIX)— ISO/IEC 10646-1:1993, Information technology — Universal Multiple-Octet Coded Character Set (UCS)— Part 1: Architecture and Basic Multilingual Plane— ISO/IEC TR 19769:2004, Information technology — Programming languages, their environments andsystem software interfaces — Extensions for the programming language C to support new characterdata types2The library described in Clause 7 of ISO/IEC 9899:1999 and Clause 7 of ISO/IEC 9899:1999/Cor.1:2001and Clause 7 of ISO/IEC 9899:1999/Cor.2:2004 is hereinafter called the C standard library.13The library described in ISO/IEC TR 19769:2004 is hereinafter called the C Unicode TR.4The operating system interface described in ISO/IEC 9945:2003 is hereinafter called POSIX .5The ECMAScript Language Specification described in Standard Ecma-262 is hereinafter called ECMA-262.1) With the qualifications noted in Clauses 18 through 30 and in C.3, the C standard library is a subset of the C++ standardlibrary.§ 1.2© ISO/IEC 2011 – All rights reserved1ISO/IEC 14882:2011(E)1.3Terms and definitions[intro.defs]1For the purposes of this document, the following definitions apply.217.3 defines additional terms that are used only in Clauses 17 through 30 and Annex D.3Terms that are used only in a small portion of this International Standard are defined where they are usedand italicized where they are defined.1.3.1[defns.argument]argumentactual argumentactual parameter<function call expression> expression in the comma-separated list bounded by the parentheses1.3.2[defns.argument.macro]argumentactual argumentactual parameter<function-like macro> sequence of preprocessing tokens in the comma-separated list bounded by the parentheses1.3.3argumentactual argumentactual parameter<throw expression> the operand of throw[defns.argument.throw]1.3.4[defns.argument.templ]argumentactual argumentactual parameter<template instantiation> expression, type-id or template-name in the comma-separated list bounded by theangle brackets1.3.5[defns.cond.supp]conditionally-supportedprogram construct that an implementation is not required to support[ Note: Each implementation documents all conditionally-supported constructs that it does not support.

—end note ]1.3.6[defns.diagnostic]diagnostic messagemessage belonging to an implementation-defined subset of the implementation’s output messages1.3.7[defns.dynamic.type]dynamic type<glvalue> type of the most derived object (1.8) to which the glvalue denoted by a glvalue expression refers§ 1.32© ISO/IEC 2011 – All rights reservedISO/IEC 14882:2011(E)[ Example: if a pointer (8.3.1) p whose static type is “pointer to class B” is pointing to an object of classD, derived from B (Clause 10), the dynamic type of the expression *p is “D.” References (8.3.2) are treatedsimilarly. — end example ]1.3.8dynamic type<prvalue> static type of the prvalue expression1.3.9ill-formed programprogram that is not well formed[defns.dynamic.type.prvalue][defns.ill.formed]1.3.10[defns.impl.defined]implementation-defined behaviorbehavior, for a well-formed program construct and correct data, that depends on the implementation andthat each implementation documents1.3.11implementation limitsrestrictions imposed upon programs by the implementation[defns.impl.limits]1.3.12[defns.locale.specific]locale-specific behaviorbehavior that depends on local conventions of nationality, culture, and language that each implementationdocuments1.3.13[defns.multibyte]multibyte charactersequence of one or more bytes representing a member of the extended character set of either the source orthe execution environment[ Note: The extended character set is a superset of the basic character set (2.3).

— end note ]1.3.14[defns.parameter]parameterformal argumentformal parameter<function or catch clause> object or reference declared as part of a function declaration or definition or inthe catch clause of an exception handler that acquires a value on entry to the function or handler1.3.15[defns.parameter.macro]parameterformal argumentformal parameter<function-like macro> identifier from the comma-separated list bounded by the parentheses immediatelyfollowing the macro name§ 1.3© ISO/IEC 2011 – All rights reserved3ISO/IEC 14882:2011(E)1.3.16parameterformal argumentformal parameter<template> template-parameter[defns.parameter.templ]1.3.17signature<function> name, parameter type list (8.3.5), and enclosing namespace (if any)[ Note: Signatures are used as a basis for name mangling and linking.

— end note ][defns.signature]1.3.18[defns.signature.templ]signature<function template> name, parameter type list (8.3.5), enclosing namespace (if any), return type, andtemplate parameter list1.3.19[defns.signature.spec]signature<function template specialization> signature of the template of which it is a specialization and its templatearguments (whether explicitly specified or deduced)1.3.20[defns.signature.member]signature<class member function> name, parameter type list (8.3.5), class of which the function is a member, cvqualifiers (if any), and ref-qualifier (if any)1.3.21[defns.signature.member.templ]signature<class member function template> name, parameter type list (8.3.5), class of which the function is a member,cv-qualifiers (if any), ref-qualifier (if any), return type, and template parameter list1.3.22[defns.signature.member.spec]signature<class member function template specialization> signature of the member function template of which it isa specialization and its template arguments (whether explicitly specified or deduced)1.3.23[defns.static.type]static typetype of an expression (3.9) resulting from analysis of the program without considering execution semantics[ Note: The static type of an expression depends only on the form of the program in which the expressionappears, and does not change while the program is executing.

— end note ]1.3.24[defns.undefined]undefined behaviorbehavior for which this International Standard imposes no requirements[ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of§ 1.344© ISO/IEC 2011 – All rights reservedISO/IEC 14882:2011(E)behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behaviorranges from ignoring the situation completely with unpredictable results, to behaving during translation orprogram execution in a documented manner characteristic of the environment (with or without the issuance ofa diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.— end note ]1.3.25[defns.unspecified]unspecified behaviorbehavior, for a well-formed program construct and correct data, that depends on the implementation[ Note: The implementation is not required to document which behavior occurs.