Стандарт C++ 98 (1119566), страница 87
Текст из файла (страница 87)
Each may be included more thanonce, with no effect different from being included exactly once, except that the effect of including either<cassert> or <assert.h> depends each time on the lexically current definition of NDEBUG.161)3A translation unit shall include a header only outside of any external declaration or definition, and shallinclude the header lexically before the first reference to any of the entities it declares or first defines in thattranslation unit.__________________159) This disallows the practice, allowed in C, of providing a "masking macro" in addition to the function prototype. The only way toachieve equivalent "inline" behavior in C++ is to provide a definition as an extern inline function.160) The ".h" headers dump all their names into the global namespace, whereas the newer forms keep their names in namespacestd.
Therefore, the newer forms are the preferred forms for all uses except for C++ programs which are intended to be strictly compatible with C.161) This is the same as the Standard C library.320© ISO/IECISO/IEC 14882:1998(E)17 Library introduction17.4.2.2 Linkage17.4.2.2 Linkage[lib.using.linkage]1Entities in the C++ Standard Library have external linkage (3.5). Unless otherwise specified, objects andfunctions have the default extern "C++" linkage (7.5).2It is unspecified whether a name from the Standard C library declared with external linkage has eitherextern "C" or extern "C++" linkage.162)3Objects and functions defined in the library and required by a C++ program are included in the programprior to program startup.SEE ALSO: replacement functions (17.4.3.4), run-time changes (17.4.3.5).17.4.3 Constraints on programs1[lib.constraints]This subclause describes restrictions on C++ programs that use the facilities of the C++ Standard Library.The following subclauses specify constraints on the program’s namespace (17.4.3.1), its use of headers(17.4.3.2), classes derived from standard library classes (17.4.3.3), definitions of replacement functions(17.4.3.4), and installation of handler functions during execution (17.4.3.5).17.4.3.1 Reserved names[lib.reserved.names]1It is undefined for a C++ program to add declarations or definitions to namespace std or namespaceswithin namespace std unless otherwise specified.
A program may add template specializations for anystandard library template to namespace std. Such a specialization (complete or partial) of a standardlibrary template results in undefined behavior unless the declaration depends on a user-defined name ofexternal linkage and unless the specialization meets the standard library requirements for the original template.163)2The C++ Standard Library reserves the following kinds of names:— Macros— Global names— Names with external linkage3If the program declares or defines a name in a context where it is reserved, other than as explicitly allowedby this clause, the behavior is undefined.17.4.3.1.1 Macro names[lib.macro.names]1Each name defined as a macro in a header is reserved to the implementation for any use if the translationunit includes the header.164)2A translation unit that includes a header shall not contain any macros that define names declared or definedin that header.
Nor shall such a translation unit define macros for names lexically identical to keywords.17.4.3.1.2 Global names1[lib.global.names]Certain sets of names and function signatures are always reserved to the implementation:— Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use.— Each name that begins with an underscore is reserved to the implementation for use as a name in the__________________162) The only reliable way to declare an object or function signature from the Standard C library is by including the header thatdeclares it, notwithstanding the latitude granted in subclause 7.1.7 of the C Standard.163) Any library code that instantiates other library templates must be prepared to work adequately with any user-supplied specialization that meets the minimum requirements of the Standard.164) It is not permissible to remove a library macro definition by using the #undef directive.321ISO/IEC 14882:1998(E)© ISO/IEC17.4.3.1.2 Global names17 Library introductionglobal namespace.165)17.4.3.1.3 External linkage[lib.extern.names]1Each name declared as an object with external linkage in a header is reserved to the implementation to designate that library object with external linkage,166) both in namespace std and in the global namespace.2Each global function signature declared with external linkage in a header is reserved to the implementationto designate that function signature with external linkage.167)3Each name having two consecutive underscores (2.11) is reserved to the implementation for use as a namewith both extern "C" and extern "C++" linkage.4Each name from the Standard C library declared with external linkage is reserved to the implementation foruse as a name with extern "C" linkage, both in namespace std and in the global namespace.5Each function signature from the Standard C library declared with external linkage is reserved to the implementation for use as a function signature with both extern "C" and extern "C++" linkage,168) oras a name of namespace scope in the global namespace.17.4.3.1.4 Types1[lib.extern.types]169)For each type T from the Standard C library,the types ::T and std::T are reserved to the implementation and, when defined, ::T shall be identical to std::T.17.4.3.2 Headers1If a file with a name equivalent to the derived file name for one of the C++ Standard Library headers is notprovided as part of the implementation, and a file with that name is placed in any of the standard places fora source file to be included (16.2), the behavior is undefined.17.4.3.3 Derived classes1[lib.alt.headers][lib.derived.classes]Virtual member function signatures defined for a base class in the C++ Standard library may be overriddenin a derived class defined in the program (10.3).17.4.3.4 Replacement functions[lib.replacement.functions]1Clauses 18 through 27 describe the behavior of numerous functions defined by the C++ Standard Library.Under some circumstances, however, certain of these function descriptions also apply to replacement functions defined in the program (17.1).2A C++ program may provide the definition for any of eight dynamic memory allocation function signaturesdeclared in header <new> (3.7.3, clause 18):— operator new(size_t)— operator new(size_t, const std::nothrow_t&)— operator new[](size_t)— operator new[](size_t, const std::nothrow_t&)__________________165) Such names are also reserved in namespace ::std (17.4.3.1).166) The list of such reserved names includes errno, declared or defined in <cerrno>.167) The list of such reserved function signatures with external linkage includes setjmp(jmp_buf), declared or defined in<csetjmp>, and va_end(va_list), declared or defined in <cstdarg>.168) The function signatures declared in <cwchar> and <cwctype> are always reserved, notwithstanding the restrictions imposedin subclause 4.5.1 of Amendment 1 to the C Standard for these headers.169) These types are clock_t, div_t, FILE, fpos_t, lconv, ldiv_t, mbstate_t, ptrdiff_t, sig_atomic_t,size_t, time_t, tm, va_list, wctrans_t, wctype_t, and wint_t.322© ISO/IEC17 Library introductionISO/IEC 14882:1998(E)17.4.3.4 Replacement functions— operator delete(void*)— operator delete(void*, const std::nothrow_t&)— operator delete[](void*)— operator delete[](void*, const std::nothrow_t&)3The program’s definitions are used instead of the default versions supplied by the implementation (8.4).Such replacement occurs prior to program startup (3.2, 3.6).17.4.3.5 Handler functions1[lib.handler.functions]The C++ Standard Library provides default versions of the following handler functions (clause 18):— unexpected_handler— terminate_handler2A C++ program may install different handler functions during execution, by supplying a pointer to a function defined in the program or the library as an argument to (respectively):— set_new_handler— set_unexpected— set_terminateSEE ALSO: subclauses 18.4.2, Storage allocation errors, and 18.6, Exception handling.17.4.3.6 Other functions[lib.res.on.functions]1In certain cases (replacement functions, handler functions, operations on types used to instantiate standardlibrary template components), the C++ Standard Library depends on components supplied by a C++ program.
If these components do not meet their requirements, the Standard places no requirements on theimplementation.2In particular, the effects are undefined in the following cases:— for replacement functions (18.4.1), if the installed replacement function does not implement the semantics of the applicable Required behavior paragraph.— for handler functions (18.4.2.2, 18.6.3.1, 18.6.2.2), if the installed handler function does not implementthe semantics of the applicable Required behavior paragraph— for types used as template arguments when instantiating a template component, if the operations on thetype do not implement the semantics of the applicable Requirements subclause (20.1.5, 23.1, 24.1,26.1).
Operations on such types can report a failure by throwing an exception unless otherwise specified.— if any replacement function or handler function or destructor operation throws an exception, unlessspecifically allowed in the applicable Required behavior paragraph.— if an incomplete type (3.9) is used as a template argument when instantiating a template component.323ISO/IEC 14882:1998(E)1© ISO/IEC17.4.3.6 Other functions17 Library introduction17.4.3.7 Function arguments[lib.res.on.arguments]Each of the following statements applies to all arguments to functions defined in the C++ Standard Library,unless explicitly stated otherwise.— If an argument to a function has an invalid value (such as a value outside the domain of the function, ora pointer invalid for its intended use), the behavior is undefined.— If a function argument is described as being an array, the pointer actually passed to the function shallhave a value such that all address computations and accesses to objects (that would be valid if thepointer did point to the first element of such an array) are in fact valid.17.4.3.8 Required paragraph1[lib.res.on.required]Violation of the preconditions specified in a function’s Required behavior paragraph results in undefinedbehavior unless the function’s Throws paragraph specifies throwing an exception when the precondition isviolated.17.4.4 Conforming implementations1[lib.conforming]This subclause describes the constraints upon, and latitude of, implementations of the C++ Standard library.The following subclauses describe an implementation’s use of headers (17.4.4.1), macros (17.4.4.2), globalfunctions (17.4.4.3), member functions (17.4.4.4), reentrancy (17.4.4.5), access specifiers (17.4.4.6), classderivation (17.4.4.7), and exceptions (17.4.4.8).17.4.4.1 Headers[lib.res.on.headers]170)1A C++ header may include other C++ headers.2Certain types and macros are defined in more than one header.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
