|
www.riscos.com Technical Support: |
This chapter describes implementation specific behaviour of the C++ Language System. Implementation specific behaviours can be categorised as follows:
This chapter addresses categories 1, 2, 4, and 5. For details about properties defined in the standard header files (category 3), see the headers themselves. Additional information about constructs that are not implemented is provided in the appendix C++ errors and warnings, which contains an alphabetical listing of the 'not implemented' error messages.
The ordering and numbering of sections in this chapter corresponds to the order and numbering of the related sections in the Reference Manual. The section Translation Limits below (which does not have a corresponding section in the Reference Manual) precedes the numbered sections.
Release 3.0 of the Acorn C++ Language System imposes the following translation limits:
Additional translation limits may be inherited from the underlying C compiler and preprocessor.
Release 3.0 reserves identifiers that contain a sequence of two underscores for its own use. In addition, identifiers reserved in the ANSI C standard are also reserved by Release 3.0. Under the +w option, identifiers with double underscores result in a warning in Release 3.0.
The Reference Manual states that the value of a multicharacter constant, such as 'abcd', is implementation dependent. Release 3.0 passes these constants to the underlying C compiler, which determines their values. A multicharacter constant containing more characters than sizeof(int) is reported as an error by Release 3.0.
The Reference Manual states that the value of a character constant is implementation dependent if it exceeds that of the largest char. Release 3.0 accepts octal and hexadecimal character literals that do not fit in a char. It uses the low order bits that make up the value of the constant. For example, the octal character constant '\777' is treated as '\377'. The hexadecimal character constant '\x123' is treated as '\x23'.
Release 3.0 does not implement wide character constants, such as L'ab'. A 'not implemented' error message is reported.
When compiling with the +a0 option, Release 3.0 removes an l or L suffix from a floating constant before passing the constant to the underlying C compiler. Under the +a1 option such a constant is passed unchanged to the underlying C compiler. In either case, the constant is considered to be of type long double for purposes of resolving overloaded function calls.
The Reference Manual states that it is implementation dependent whether all string literals are distinct. Release 3.0 does not attempt to detect cases where string literals could be represented as overlapping objects. The underlying C compiler may, however, detect such cases and attempt to overlap their storage.
Release 3.0 does not implement wide character strings, such as L"abcd". A 'not implemented' error message is reported.
The Reference Manual states that the type of main() is implementation dependent. Release 3.0 itself does not impose any restrictions on the type of main(), but the underlying C compiler or the target environment may impose such restrictions.
The Acorn C++ Language System treats main() as if its linkage were extern "C".
Release 3.0 does not implement the type specifier signed; it issues a warning and proceeds as though the specifier signed had not appeared.
When Release 3.0 is invoked with the +a0 option, the type long double is considered to be the same size and precision as the type double in the underlying C compiler. Under the +a1 option, long double is passed to the underlying C compiler as long double. In either case, type long double is considered a distinct type for purposes of resolving overloaded function declarations and invocations.
Release 3.0 does not impose any alignment restrictions when allocating objects of a particular type. Such restrictions, if they exist, are enforced by the underlying C compiler.
When a value of an integral type is converted to a signed integral type with fewer bits in the representation, Release 3.0 issues a warning message if the +w option is specified. The runtime behaviour of such a conversion depends on the treatment of the conversion by the underlying C compiler.
The Reference Manual states that the handling of overflow and divide check in expression evaluation is implementation dependent. When the second operand of a division or modulus operator is known to be zero at compile time, Release 3.0 reports an error. Overflow and other divide check conditions are handled by the underlying C compiler and execution environment.
The Reference Manual states that the order of evaluation of arguments to a function call is implementation dependent; similarly, the order of evaluation of the postfix expression, which designates the function to be called, and the argument expression list are implementation dependent. In both cases the order depends on the treatment by the underlying C compiler.
The Reference Manual states that the value obtained by explicitly converting a pointer to an integral type large enough to hold it is implementation dependent. This behaviour is defined by the underlying C compiler. Similarly, the behaviour when explicitly converting an integer to a pointer depends on the underlying C compiler.
The Reference Manual states that the sign of the result of the modulus operator is non-negative if both operands are non-negative; otherwise, the sign of the result is implementation dependent. This behaviour depends on the underlying C compiler except when the values of both operands are known at compile time. In this case, the sign of the result is the same as the sign of the numerator.
The Reference Manual states that the result of a right shift when the left operand is a signed type with a negative value is implementation dependent. This behaviour depends on the underlying C compiler.
According to the Reference Manual, certain pointer comparisons are implementation dependent. For Release 3.0, the results of these comparisons depend on the underlying C compiler.
The Reference Manual states that the inline specifier is a hint to the compiler.
When compiling with the +d option, Release 3.0 always generates out-of-line calls to inline functions.
Release 3.0 does not implement the type specifier volatile. If it is applied to a member function, a 'not implemented' error message is issued; otherwise it is ignored and a warning message is issued.
Release 3.0 does not implement the type specifier signed; it is ignored and a warning message is issued.
Release 3.0 passes asm declarations to the underlying C compiler without modification. However, the compiler supplied with Acorn C/C++ will fault them.
Release 3.0 supports linkage to C and C++.
The effect of a "C" linkage specification (extern "C") on a function that is not a member function is that the function name is not encoded with type information, as is otherwise done for C++ functions. Member functions are not affected by linkage specifications.
The C linkage specification (extern "C"), when applied to a non-function declaration, does not affect the C code generated.
The Reference Manual states that the order of allocation of non-static data members across access-specifiers is implementation dependent. Release 3.0 allocates non-static data members in declaration order.
The Reference Manual states that the allocation and alignment of bitfields within a class object is implementation dependent. Responsibility for the allocation and alignment of bitfields rests with the underlying C compiler.
Whether the high-order bit position of a 'plain' int bitfield is treated as a sign bit depends on the behaviour of the underlying C compiler.
The Reference Manual states that the order in which storage is allocated for base classes is implementation dependent. For non-virtual base classes, Release 3.0 allocates storage in the order that they are mentioned in the derived class declaration.
The type of the result of an integral promotion (4.1) depends on the execution environment, as does the type of an unsuffixed integer constant (2.5.1). Consequently, the determination of which overloaded function to call may also depend on the execution environment, as illustrated by an example in 13.2 of the Reference Manual.
Release 3.0 does not implement exception handling. The keyword catch is reserved for future use. A 'not implemented' error message is reported if catch is seen.
The following macros are defined by Release 3.0:
| __cplusplus | The decimal constant 1. |
| c_plusplus | The decimal constant 1. This macro is provided for compatibility with previous releases and will not be supported in the next major release. |
Other macros may be predefined by the underlying preprocessor.