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

For such an entity, a second or subsequentheader that also defines it may be included after the header that provides its initial definition (3.2).3Header inclusion is limited as follows:— The C headers ( .h form, described in Annex D, D.5) shall include only their corresponding C++header, as described above (17.4.1.2).17.4.4.2 Restrictions on macro definitions[lib.res.on.macro.definitions]1The names or global function signatures described in 17.4.1.1 are reserved to the implementation.2All object-like macros defined by the Standard C library and described in this clause as expanding to integral constant expressions are also suitable for use in #if preprocessing directives, unless explicitly statedotherwise.17.4.4.3 Global functions[lib.global.functions]1It is unspecified whether any global functions in the C++ Standard Library are defined as inline (7.1.2).2A call to a global function signature described in Clauses 18 through 27 behaves the same as if the implementation declares no additional global function signatures.171)3A global function cannot be declared by the implementation as taking additional default arguments.__________________170) C++ headers must include a C++ header that contains any needed definition (3.2).171) A valid C++ program always calls the expected library global function.

An implementation may also define additional globalfunctions that would otherwise not be called by a valid C++ program.324© ISO/IECISO/IEC 14882:1998(E)17 Library introduction17.4.4.4 Member functions17.4.4.4 Member functions[lib.member.functions]1It is unspecified whether any member functions in the C++ Standard Library are defined as inline(7.1.2).2An implementation can declare additional non-virtual member function signatures within a class:— by adding arguments with default values to a member function signature;172) The same latitude does notextend to the implementation of virtual or global functions, however.— by replacing a member function signature with default values by two or more member function signatures with equivalent behavior;— by adding a member function signature for a member function name.3A call to a member function signature described in the C++ Standard library behaves the same as if theimplementation declares no additional member function signatures.173)17.4.4.5 Reentrancy1Which of the functions in the C++ Standard Library are not reentrant subroutines is implementationdefined.17.4.4.6 Protection within classes1[lib.reentrancy][lib.protection.within.classes]It is unspecified whether a function signature or class described in clauses 18 through 27 is a friend ofanother class in the C++ Standard Library.17.4.4.7 Derived classes[lib.derivation]1It is unspecified whether a class in the C++ Standard Library is itself derived from other classes (withnames reserved to the implementation).2Certain classes defined in the C++ Standard Library are derived from other classes in the C++ StandardLibrary:— It is unspecified whether a class described in the C++ Standard Library as derived from another class isderived from that class directly, or through other classes (with names reserved to the implementation)that are derived from the specified base class.3In any case:— A base class described as virtual is always virtual;— A base class described as non-virtual is never virtual;— Unless explicitly stated otherwise, types with distinct names are distinct types.174)17.4.4.8 Restrictions on exception handling1[lib.res.on.exception.handling]Any of the functions defined in the C++ Standard Library can report a failure by throwing an exception ofthe type(s) described in their Throws: paragraph and/or their exception-specification (15.4).

An implementation may strengthen the exception-specification for a function by removing listed exceptions.175)__________________172) Hence, taking the address of a member function has an unspecified type.173) A valid C++ program always calls the expected library member function, or one with equivalent behavior. An implementationmay also define additional member functions that would otherwise not be called by a valid C++ program.174) An implicit exception to this rule are types described as synonyms for basic integral types, such as size_t (18.1) andstreamoff (27.4.1).175) That is, an implementation of the function will have an explicit exception-specification that lists fewer exceptions than those specified in this International Standard.

It may not, however, change the types of exceptions listed in the exception-specficiation from thosespecified, nor add others.325ISO/IEC 14882:1998(E)17.4.4.8 Restrictions on exception handling© ISO/IEC17 Library introduction2None of the functions from the Standard C library shall report an error by throwing an exception,176) unlessit calls a program-supplied function that throws an exception.177)3No destructor operation defined in the C++ Standard Library will throw an exception.

Any other functionsdefined in the C++ Standard Library that do not have an exception-specification may throwimplementation-defined exceptions unless otherwise specified.178) An implementation may strengthen thisimplicit exception-specification by adding an explicit one.179)__________________176) That is, the C library functions all have a throw() exception-specification. This allows implementations to make performanceoptimizations based on the absence of exceptions at runtime.177) The functions qsort() and bsearch() (25.4) meet this condition.178) In particular, they can report a failure to allocate storage by throwing an exception of type bad_alloc, or a class derived frombad_alloc (18.4.2.1).

Library implementations are encouraged (but not required) to report errors by throwing exceptions from (orderived from) the standard exception classes (18.4.2.1, 18.6, 19.1).179) That is, an implementation may provide an explicit exception-specification that defines the subset of ‘‘any’’ exceptions thrown bythat function. This implies that the implementation may list implementation-defined types in such an exception-specification.326© ISO/IECISO/IEC 14882:1998(E)18 Language support library[lib.language.support]1This clause describes the function signatures that are called implicitly, and the types of objects generatedimplicitly, during the execution of some C++ programs.

It also describes the headers that declare thesefunction signatures and define any related types.2The following subclauses describe common type definitions used throughout the library, characteristics ofthe predefined types, functions supporting start and termination of a C++ program, support for dynamicmemory management, support for dynamic type identification, support for exception processing, and otherruntime support, as summarized in Table 14:Table 14—Language support library summary________________________________________________________________________________________________SubclauseHeader(s)________________________________________________18.1 Types<cstddef>________________________________________________<limits> 18.2 Implementation properties<climits><cfloat>________________________________________________18.3 Start and termination<cstdlib>________________________________________________________________________________________________18.4 Dynamic memory management <new>18.5 Type identification<typeinfo> ________________________________________________18.6 Exception handling<exception> ________________________________________________<cstdarg><csetjmp><ctime> 18.7 Other runtime support<csignal>________________________________________________<cstdlib>18.1 Types[lib.support.types]1Common definitions.2Header <cstddef> (Table 15):Table 15—Header <cstddef> synopsis__________________________________________________________________________KindName(s)Macros: NULLoffsetof__________________________________________________________________________Types:ptrdiff_tsize_t3The contents are the same as the Standard C library header <stddef.h>, with the following changes:4The macro NULL is an implementation-defined C++ null pointer constant in this International Standard(4.10).180)__________________180) Possible definitions include 0 and 0L, but not (void*)0.327ISO/IEC 14882:1998(E)© ISO/IEC18.1 Types518 Language support libraryThe macro offsetof accepts a restricted set of type arguments in this International Standard.

typeshall be a POD structure or a POD union (clause 9). The result of applying the offsetof macro to a field thatis<b>Текст обрезан, так как является слишком большим</b>.