RISCOS.com

www.riscos.com Technical Support:
Acorn C/C++

 

C++ implementation details


This chapter describes implementation specific behaviour of the C++ Language System. Implementation specific behaviours can be categorised as follows:

  1. Behaviour that the Reference Manual defines as 'implementation dependent'
  2. Behaviour that depends on the underlying C compiler or preprocessor used with Release 3.0
  3. Properties that are defined in the standard header files stddef.h, limits.h, and stdlib.h
  4. Translation limits
  5. Language constructs that are not implemented in this release.

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.

Translation Limits

Release 3.0 of the Acorn C++ Language System imposes the following translation limits:

  • 50 nesting levels of compound statements
  • 10 nesting levels of linkage declarations
  • 4088 characters in a token
  • 22222 virtual functions in a class
  • 10000 identifiers generated by the implementation.

Additional translation limits may be inherited from the underlying C compiler and preprocessor.

Identifiers (2.3)

Identifiers reserved by Release 3.0

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.

Character Constants (2.5.2)

Value of multicharacter constants

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.

Value of (single) character constants

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'.

Wide character constants

Release 3.0 does not implement wide character constants, such as L'ab'. A 'not implemented' error message is reported.

Floating Constants (2.5.3)

Long double floating constants

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.

String Literals (2.5.4)

Distinct string literals

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.

Wide character strings

Release 3.0 does not implement wide character strings, such as L"abcd". A 'not implemented' error message is reported.

Start and Termination (3.4)

Type of main()

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.

Linkage of main()

The Acorn C++ Language System treats main() as if its linkage were extern "C".

Fundamental Types (3.6.1)

Signed integral types

Release 3.0 does not implement the type specifier signed; it issues a warning and proceeds as though the specifier signed had not appeared.

Long double type

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.

Alignment requirements

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.

Integral Conversions (4.2)

Conversion to a signed type

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.

Expressions (5)

Overflow and divide check

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.

Function Call (5.2.2)

Evaluation order

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.

Explicit Type Conversion (5.4)

Explicit conversions between pointer and integral types

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.

Multiplicative Operators (5.6)

Sign of the remainder

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.

Shift Operators (5.8)

Result of right shift

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.

Relational Operators (5.9)

Pointer comparisons

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.

Storage Class Specifiers (7.1.1)

Inline functions

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.

Type Specifiers (7.1.6)

Volatile

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.

Signed

Release 3.0 does not implement the type specifier signed; it is ignored and a warning message is issued.

Asm Declarations (7.3)

Effect of an asm declaration

Release 3.0 passes asm declarations to the underlying C compiler without modification. However, the compiler supplied with Acorn C/C++ will fault them.

Linkage Specifications (7.4)

Languages supported

Release 3.0 supports linkage to C and C++.

Linkage to functions

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.

Linkage to non-functions

The C linkage specification (extern "C"), when applied to a non-function declaration, does not affect the C code generated.

Class Members (9.2)

Allocation of non-static data members

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.

Bitfields (9.6)

Allocation and alignment of bitfields

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.

Sign of 'plain' bitfields

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.

Multiple Base Classes (10.1)

Allocation of base classes

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.

Argument Matching (13.2)

Integral arguments

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.

Exception Handling (experimental) (15)

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.

Predefined Names (16.10)

Predefined macros

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.

© 3QD Developments Ltd 2013