All of the implementation-defined features based on the ANSI/ISO C standard that have already been described in chapter “C language support of the compiler” (Implementation-defined behavior based on the ANSI/ISO C standard ) are also applicable in the C++ language modes and are therefore not listed individually here.
Only the implementation-defined C++ language features that extend beyond the scope of the C language are described below. Which C ++ language features are supported in which C++ modes can be found in the tabular overview on "Overview of the C++ language modes".
Identifiers with external linkage
Compilation in the Cfront C++ mode
External C++ names are truncated by the compiler to 32 characters. When generating shared code (with the options-K shareor SHAREABLE-CODE=*YES), the maximum permissible length is restricted to 30 characters.
Lowercase letters are converted to uppercase by default, but can be retained in external names with the option-K llm_case_loweror LOWER-CASE-NAMES=*YES.Compilation in the modes C++ V3, C++ 2017 or C++ 2020
All characters are significant for the construction of external C++ names. No name truncation and no conversion from lowercase to uppercase occurs. The compiler generates entry names in the EEN format, which can have a length of up to 32000 characters. Longer names result in an error.
To enable processing by the link editor, names with external C++ linkage are transformed internally by the compiler so that they only contain permitted characters and are unique (name mangling). This internal name mangling process differs in the Cfront C++ mode and in the other C++ modes. A list of the originally used external C++ names and those which were generated internally by the compiler for the linkage editor can be obtained with the option -N project or PROJECT-INFORMATION=*YES.
Linkage of the main function
The main function has external C linkage.
Data type bool
The size of type bool is defined as sizeof(bool) == 1.
reinterpret_cast
The destination object contains the same bit pattern as the expression evaluated by reinterpret_cast, but might not be a valid object of the desired type (e.g. reinterpret_cast<float>(int)).
The following conversions are possible:
A pointer can be explicitly converted to an integral type that is large enough to hold it. Depending on whether the destination type is
signedorunsigned, the value of the result obtained from the conversion may or may not be signed.The value of an integral type can be explicitly converted to a pointer.
Allocation overhead for new arrays
For each allocated array, a structure is reserved at the start of the memory block allocated for that array. This structure contains two size_t members, one for the size of the array (in bytes) and one for the number of elements in the array (this field is encoded in order to detect whether the structure has been overwritten).
The asm keyword
The asm keyword is an extension to the ANSI/ISO C standard, but is defined as a normal reserved keyword in the ANSI C++ standard. However, since the inline substitution of assembler code is not supported, any attempt to use this keyword will result in an error message.
Linkage specification
The supported linkage specifications are “C++” and “C”.
The default linkage specification is "C++". Names with external C++ linkage are transformed internally by the compiler to enable processing by the linkage editor (name mangling). This internal name transformation is done differently in the different C ++ modes.
In the case of names with external C linkage, no internal name mangling is performed. C linkage can be used to link and call functions written in C or in a language that behaves like C on its name mangling interface.
A pointer to a C function is compatible with a pointer to a C++ function of the same type if the argument types are C-compatible PODs. In C++ 2017, these are two different types. In the extended C++ 2017 mode there is an implicit conversion between two function types that only differ in the linkage.
Linkage of templates
Only templates with C++ linkage are supported.
Template instantiation
Reference types
The reference for an value is bound to a temporary object created by the compiler.Internally, the C++ data type reference is treated as a pointer (see "Implementation-defined behavior based on the ANSI/ISO C standard (C/C++-Compiler, #89)").
Allocation of non-static data elements of a class
The allocation of memory for these data elements occurs in the strict order of their declarations, i.e. without taking the access specifiers public, private or protected into account.
Bitfields within classes
Bitfields within classes are handled in the same way as bitfields within structures. This applies to the allocation and alignment as well as the handling of “plain” bitfields without the signed or unsigned attribute.
Constructors and destructors for global and local static objects
C++ supports the initialization and finalization of objects with constructors and destructors. Constructor and destructor calls can be applied on both dynamic as well as global and local static objects.
Constructors and destructors for dynamic objects
Constructors for dynamic objects are called when objects are created with the new operator, on entering functions or local blocks, on processing actual parameters, and when temporary objects are created.
Destructors for dynamic objects are called in the reverse order of their construction, e.g. on exiting a function (return, exit), block, etc.
If temporary objects are created for an expression, the destructors are called at the end of the expression. This applies in particular to function parameters.
Constructors and destructors for global and local static objects
The type and order of constructor and destructor calls for global and local static objects is “implementation-defined”. Seen from a technical viewpoint, this means the following:
Constructor calls are collected in one function per compilation unit, and the address of each such function is stored in a specially marked variable in the data section of the program. During the initialization of the runtime system, a list of these variables is generated, and the constructors are called before the main function. Destructors are called on exiting a program normally, i.e. on calling exit, _exit, bs2exit or return from the main function, but not on calling abort.
Seen from the user ́s perspective, the following points must be observed when using global and local static objects with constructors and destructors:
The redirection of standard I/O files (see "Redirecting standard I/O files (C/C++-Compiler, #72)") has no effect within global and local static objects.
The order in which constructors are called is totally undefined and may actually vary even when running the same program. It is therefore crucial to ensure that no dependencies between the individual constructor calls exist.
The names of the special variables for constructor function addresses (see above) begin with ICP. This prefix and the initial letter
Iin general must not be used when constructing user-defined external names, since this produces errors in constructor handling.ESD information must not be suppressed when linking.
The data of the program must be in class-6 memory.
In the case of shared code, all code segments to call constructors are loaded dynamically.
No inter-language linkage is permitted within a destructor (only linkage to other languages).
No code may be “unloaded”; otherwise, on exiting the program, this would result in destructors being called for code that no longer exists.
In the case or true subsystems for which data and code are loaded dynamically with an explicit call, the runtime system must be reinitialized. During this process, the table of constructors is extended, and the new constructors are called.
Exception handling
Thrown exceptions
The memory for exception objects is taken from a preallocated storage, which can be extended by calls to malloc.
Handling of exceptions
In some situations, the terminate () function is called implicitly. The C++ standard leaves open the question in two situations whether destructors are called for automatic objects:
If no suitable exception handler is found, the destructors are not called.
If there is a function on the stack that specifies noexcept(true), only some of the destructors are called.
These destructors could be executed with the function unwind_exit(), (see "Additional runtime functions").
The unexpected() function
The thrown exception object which causes the unexpected() function to fail is destroyed by calling a destructor and is replaced by a new bad_exception object.
More details on exception handling can be found on "Exception handling".
Return type of operator->
The return type of operator->() is not checked any more at the point where the function is declared, but is now only checked at the point where it is used as an “->” operator. (This check was performed later on just for elements of class templates in versions up to V3.0C.)
Classes and Ellipsis
Functions can be declared with variable argument lists (e.g. int foo(int, ...);). An object of a class can be a parameter if the appropriate argument is the ellipsis. In this case the object is copied byte by byte. Any constructor that may exist is ignored. Any existing destructor is not called for the parameter.