INTERNATIONAL STANDARD 1S01EC14882:2011(E 1 General intro] 1.1 Scope [intro.scope] 1 This International Standard specifies requirements for implementations of the C4+programming langage. The first sch requirement is that they implement the language,and so this Internatiooal Standard also defines C++.Other roquirements and relaxatioess of the first requirement appear at various places within this International Standard. 2 C++is a general purpooe programming langage based on the C programming language as spocifiod in IS0/IEC 9899:1999,Programming languages-C (hereinafter referred to ns the C standand).In addition to the facilities prenvided by C.C++pruvides additional data types,cles,templates,exeptions,namespncs, operator overlonding.fumction name overloading.references,free store management operators,and additional libeary facilities. 1.2 Normative references [intro.refs] 1 The following referenced documents are indisperesable for the application of this document.For dated refer enees,only the edition cited applies.For undated referemes,the latest edition of the refereneed document (ncluding any amendmemts）applies. -Eema Internatlonal,ECMASeript Lenguage Specification,Standard Eemn-262,third editlon,199. -ISO/IEC 2382 (all parts),Information tecknoloyy-Vocubuiary 一1S0/1ECs9g:199m,Programming lengue9e一C -150/TEC 9899:1999/Cor.1-2001(E).Proyrmming languages-C.Technical Corrigendvm I -150/IEC 9899:1909/Cor.2-2001(E),Proyrmming lenguagrs-C.Technicnl Corrigendvm -IS0/IEC 9899:1999/Cor.2007(E).Proyramming languages-C.Technical Corrigendum 3 -IS0/IEC 9945:20013,Information techaology-Portalle Operating Syatem Interface (POSIX) -IS0/TEC10646-1:19 Information techmology-Unfversal Multiple-Octet Coded Character Set (UCS) -Part 1:Arckitectare and Basic Muitilingual Plane -IS0/IEC TR 19769:2004,Information technologg-Progrumming langwoges,their enviromments and system softare interfaces -Ezteasions for the proyruming languoge C to support new charcter d如wes 2 The lbrary described in Clause 7 of ISO/IEC 9899:1999 and Clause 7 of ISO/IEC 9899:1999/Cor.1:2001 and Clause 7 of SO/IEC 9599:1909/Cor.2:2004 is hereinafter ealled the C standand lilrury. 3 The libeary described in IS0/IEC TR 19760:2004 is hereinafter called the C Unicode TR. The operating system Interface deseribed in ISO/IEC945:2013 is bereinafter called POSIY. The ECMAScript Language Specifention described in Standard Ecma-262 is hereinafter called ECMA-262. library. 51.2 DSOEC 2011 -Al rights teserwd 1
1.1 Scope [intro.scope] 1 This 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 also defines C++. Other requirements and relaxations of the first requirement appear at various places within this International Standard. 2 C++ is a general purpose programming language based on the C programming language as specified in ISO/IEC 9899:1999 (hereinafter referred to as the C standard). In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, operator overloading, function name overloading, references, free store management operators, and additional library facilities. 1.2 Normative references [intro.refs] 1 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 echnology — 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 and system software interfaces — Extensions for the programming language C to support new character data types 2 The library described in Clause 7 of ISO/IEC 9899:1999 and Clause 7 of ISO/IEC 9899:1999/Cor.1:2001 and Clause 7 of ISO/IEC 9899:1999/Cor.2:2004 is hereinafter called the C standard library. 1 3 The library described in ISO/IEC TR 19769:2004 is hereinafter called the C Unicode TR. 4 The operating system interface described in ISO/IEC 9945:2003 is hereinafter called POSIX. 5 The 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++ standard library. § 1.2 © ISO/IEC 2011 – All rights reserved 1 , Programming languages — C t INTERNATIONAL STANDARD ISO/IEC 14882:2011(E) 1 General [intro]
S01EC14882:2011(E) 1.3 Terms and definitions [intro.defs] 1 For the purpoes of this document,the folkring definitions apply. 2 17.3 defipes additional terms that are used oaly in Clauses 17 throgh 30 and Annex D. a Ters that are used only in a small portion of this International Standard are defined where they are used and italicized where they are defined. 1.3.1 (defns.argument] argument actual argumeat actual parameter cfunction call exxpression>epression in the comma-separated lst bounded by the parentheses 1.3.2 defns.argument.macro argument actual argumemt actual parameter cfumction-like maero>sxqquenee of peeprocosing tobens in the comma-separated list bounded bry the paren- theses 13.3 defns.argument.throw argument actual argumnest actual parameter cthrow expression>the operand of thro 1.3.d defns.argument.templ argument actual argument actual parameter <template instantiation>exprsion,gpe-id or femplade-name in the comma-seprated list bounded by the angle beackets 13.5 defns.cond.supp) condltlonally-supported program comstruct that an implementation is not rexpuird to support Note:Each implementation documents all cooditionally-supported comnstructs that it does not support.- ead note] 1.3.6 defns.dlagnostlc diagnostie message meesage helonging to an implementatioo-defined subeet of the implementation's output messages 1.3.7 defns.dynamic.type dynamic type <ghh>type of the most derived ol小jet(to whic由e小alue denoted by a gl小le expressiom refers s1.3 2 oS0EC2011-A创g电d0d
1.3 Terms and definitions [intro.defs] 1 For the purposes of this document, the following definitions apply. 2 17.3 defines additional terms that are used only in Clauses 17 through 30 and Annex D. 3 Terms that are used only in a small portion of this International Standard are defined where they are used and italicized where they are defined. 1.3.1 [defns.argument] argument actual argument actual parameter <function call expression> expression in the comma-separated list bounded by the parentheses 1.3.2 [defns.argument.macro] argument actual argument actual parameter <function-like macro> sequence of preprocessing tokens in the comma-separated list bounded by the parentheses 1.3.3 [defns.argument.throw] argument actual argument actual parameter <throw expression> the operand of throw 1.3.4 [defns.argument.templ] argument actual argument actual parameter <template instantiation> expression, type-id or template-name in the comma-separated list bounded by the angle brackets 1.3.5 [defns.cond.supp] conditionally-supported program 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 message message belonging to an implementation-defined subset of the implementation’s output messages 1.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.3 ISO/IEC 14882:2011(E) 2 © ISO/IEC 2011 – All rights reserved
IS01EC14882:2011(E [Erample:if a pointer (83.1)p whose static type is "pointer to clos B"is painting to an objeet of elass D.derived from B (Clause 10).the dynamic type of the expression *p is"D."References (8.32)are treated milarly.一end eraxople 1.3.8 [defns.dynamic.type.prvalue] dynamic type cprvale>statie type of the prvalue expression 1.3.9 〔defns.ill..formed ill-formed program program tha球iso味well formed 1.3.10 defns.impl.defined] implementation-defined behavior behavior,for a well-formed program construct and correct data,that depends on the implementation and that ench lmplementatsom documents 1.3.11 defns,.ipl.limit网 implementation limits restrfetions Impooed upon programs by the Implementatson 1.3.12 defns.locale.specific] locale-specifie behavior behavior that depends on local conventions of nationality.culture,and langnage that each impkmentation docments 1.3.13 defns.multibyte multibyte character sequence of ome or more bytes representing a memher of the extended character set of either the source or the execution enviromment Note:The extendod character set is a superset of the basic charncter set (2.3).-end note] 1.3.14 [def线parameter] parameter formal argument formal parameter <function oe catch clane object or reference declared as part of a function deelaration or definition or in the catch clause of an exception bandler that acquires a value on entry to the function or handker 1.3.15 defns.parameter.macro 病rameter formal argument formal prameter cfunctiom-like macros identiter from the comma-separated list bounded by the parentheses immediately following the macro name 51.3 ●50MEC2011=Ad事teed 3
[Example: if a pointer (8.3.1) p whose static type is “pointer to class B” is pointing to an object of class D, derived from B (Clause 10), the dynamic type of the expression *p is “D.” References (8.3.2) are treated similarly. — end example ] 1.3.8 [defns.dynamic.type.prvalue] dynamic type <prvalue> static type of the prvalue expression 1.3.9 [defns.ill.formed] ill-formed program program that is not well formed 1.3.10 [defns.impl.defined] implementation-defined behavior behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents 1.3.11 [defns.impl.limits] implementation limits restrictions imposed upon programs by the implementation 1.3.12 [defns.locale.specific] locale-specific behavior behavior that depends on local conventions of nationality, culture, and language that each implementation documents 1.3.13 [defns.multibyte] multibyte character sequence of one or more bytes representing a member of the extended character set of either the source or the execution environment [ Note: The extended character set is a superset of the basic character set (2.3).— end note ] 1.3.14 [defns.parameter] parameter formal argument formal parameter <function or catch clause> object or reference declared as part of a function declaration or definition or in the catch clause of an exception handler that acquires a value on entry to the function or handler 1.3.15 [defns.parameter.macro] parameter formal argument formal parameter <function-like macro> identifier from the comma-separated list bounded by the parentheses immediately following the macro name § 1.3 ISO/IEC 14882:2011(E) © ISO/IEC 2011 – All rights reserved 3
1S0/1EC14882:2011(但) 1.3.16 [defns.parameter.templ] parameter formal argmment formal parameter Ctemplate>femplele-pamaueler 1.3.17 [defns.signature] signature <function>name,parnmeter type list(8&S,and cco血g namespace(道ay） Note:Signatures are nsed as a basis for name mangling and linking.-ead note] 1.3.18 [defns.signature.templ] signature <function template>name,parameter type hist (8.3.5),enckeing namespace (f any).return type,and tet可plate parameter list 1.3.19 defns.slgnature.spec signature <function template specialization>signature of the template of which it is a specialization and its template arguments (whether explicitly speeified or deduced) 1.3.20 defns.signature.member signature <class member function>name,parameter type list (8.3.5),clases of which the function is a member,cu qualilbers (if any),and ref-qualier (if any) 1.3.21 defns.signature.member.templ signature <class member function template>name,parameter type list (8.3.5),claes of which the function is a member, equalifiers (f any),ref-qualifer (if any).return type,and template parameter list 1.3.22 defns.signature.member.spec] signature <class member function template specialization>signature of the member functico template of which it is a specialization and its template argumemts (whether explicitly specified c dedncod) 1.3.23 [defns.static.type] statie type type of an expression (3.9)resulting from analysis of the program without considering execution semantics Note:The statle type of an expeessioa depends ouly on the form of the program in which the expresson appears,and does not change while the program is executing -end note] 1.3.24 [defns.undefined] undefined behavior behmvior for which this International Stanxdard lmpcoes no requirements Note:Undefined behavior may be expected when this International Standard omits any explicit definition of 51.3 4 ●0EC2011-Al nghts4wd
1.3.16 [defns.parameter.templ] parameter formal argument formal parameter <template> template-parameter 1.3.17 [defns.signature] signature <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 ] 1.3.18 [defns.signature.templ] signature <function template> name, parameter type list (8.3.5), enclosing namespace (if any), return type, and template parameter list 1.3.19 [defns.signature.spec] signature <function template specialization> signature of the template of which it is a specialization and its template arguments (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 list 1.3.22 [defns.signature.member.spec] signature <class member function template specialization> signature of the member function template of which it is a specialization and its template arguments (whether explicitly specified or deduced) 1.3.23 [defns.static.type] static type type 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 expression appears, and does not change while the program is executing. — end note ] 1.3.24 [defns.undefined] undefined behavior behavior for which this International Standard imposes no requirements [ Note: Undefined behavior may be expected when this International Standard omits any explicit definition of § 1.3 4 ISO/IEC 14882:2011(E) 4 © ISO/IEC 2011 – All rights reserved
1s0MEC14882:2011(E behaior or when a program tses an erroeeous comstruct or erromeomus data.Permissible undefined behavior ranges fromn ignoring the situation completely with upeedsctable results.to behavingg during tmnslation or program executiom in a documented manner charaeteritic of the enviroement (uith or without the ismnce of a diagnoestic message).to terminating a translation or execution (with the issuance of a dingnostic meseage). Many erronoous program coestructs do not engender undefined behmior;they are required to be dinggnosed. 一end note 1.3.25 [dlefns.unspecifie×l unspecified behavior behavior,for a well-formed peogram construet and correet data,that depends on the implementatioe Note:The Implementatson is not required to document which behavioe occurs.The range of poooible behaviors is ussally delineated by this Intermtional Standard.-end mote 1.3.26 defns.well.formed] well-formed program C++program constracted according to the syntax rules,diagnoeable semantic rules,and the One Definition Re32) 1.4 Implementation compliance intro.compliance 1 The set of diemosable rules consists of all syntactic and semantic rules in this International Standard except for thooe rules comtaining an explicit notation that "no dingnostic is requlrod"or which are described ns resulting in "undefined behavior." 3 Although this International Standard states only requirements on C++implementations,those requirements are often easier to understand if they are phrased as requirements on programs,parts of program,or execution of programs.Such requirememts have the folkwing meaning -If a program contains no violations of the rules in this Internatiomal Standard,a conforming imple. menation shall,within its resouree limits,acopt and correctly eecute?that peogram. If a program contains a violation of any diagnosable rule or an oocurrence of a comstruct described in this Standard as "comditionally-supported"wben the lmplementatiom does not support that coestruct, a conforming implementation shall isue at least one diagnoetic meseage. If n program contains a violation of a rule for which no diagnoetic is required,thiss International Standard places no requirememt on implemenations with respeet to that program. 3 For classes and class temmplates,the library Clamses specify partial definitions.Private members(Clause 11) are not specifed,but ench implementation shall supply them to oomplete the definitions aceording to the decription in the library Clanses. 4 For fimnctions,function templates,objects,and valoes,the library Clauses specify declarations.Implemen. tations shall supply definitions consistent with the deseriptions in the library Cluses. The names defined i the lbeary have namespace scope (7.3).A C++translation unit (2.2)obtains access to these pmes by inchding the appropriate standard libeary hender (162). 6 The templates,casees.functions,and objects in the libeary have external linkage (3.5).The implementation provides definitions for standard libeary entities as necesry,while combining tramlation units to form a Gap4eC++pf0g田(2.2 s1.4 SOMEC 2011-Al rights seserved 5
behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a 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 behavior behavior, 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. The range of possible behaviors is usually delineated by this International Standard. — end note ] 1.3.26 [defns.well.formed] well-formed program C++ program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition Rule (3.2). 1.4 Implementation compliance [intro.compliance] 1 The set of diagnosable rules consists of all syntactic and semantic rules in this International Standard except for those rules containing an explicit notation that “no diagnostic is required” or which are described as resulting in “undefined behavior.” 2 Although this International Standard states only requirements on C++ implementations, those requirements are often easier to understand if they are phrased as requirements on programs, parts of programs, or execution of programs. Such requirements have the following meaning: — If a program contains no violations of the rules in this International Standard, a conforming implementation shall, within its resource limits, accept and correctly execute2 that program. — If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message. — If a program contains a violation of a rule for which no diagnostic is required, this International Standard places no requirement on implementations with respect to that program. 3 For classes and class templates, the library Clauses specify partial definitions. Private members (Clause 11) are not specified, but each implementation shall supply them to complete the definitions according to the description in the library Clauses. 4 For functions, function templates, objects, and values, the library Clauses specify declarations. Implementations shall supply definitions consistent with the descriptions in the library Clauses. 5 The names defined in the library have namespace scope (7.3). A C++ translation unit (2.2) obtains access to these names by including the appropriate standard library header (16.2). 6 The templates, classes, functions, and objects in the library have external linkage (3.5). The implementation provides definitions for standard library entities, as necessary, while combining translation units to form a complete C++ program (2.2). 2) “Correct execution” can include undefined behavior, depending on the data being processed; see 1.3 and 1.9. § 1.4 ISO/IEC 14882:2011(E) © ISO/IEC 2011 – All rights reserved 5