C++ Producer Guide

March 1998

2.6.1 - Arithmetic types

2.6.2 - Integer literal types

2.6.3 - Bitfield types

2.6.4 - Generic pointers

2.6.5 - Undefined conversions

2.6.6 - Integer division

2.6.7 - Calling conventions

2.6.8 - Pointers to data members

2.6.9 - Pointers to function members

2.6.10 - Class layout

2.6.11 - Derived class layout

2.6.12 - Constructors and destructors

2.6.13 - Virtual function tables

2.6.14 - Run-time type information

2.6.15 - Dynamic initialisation

2.6.16 - Exception handling

2.6.17 - Mangled identifier names

2.6. Implementation details

This section describes various of the implementation details of the C++ producer TDF output. In particular it describes the standard TDF tokens used to represent the target dependent aspects of the language and to provide links into the run-time system. Many of these tokens are common to the C and C++ producers. Those which are unique to the C++ producer have names of the form ~cpp.*. Note that the description is in terms of TDF tokens, not the internal tokens introduced by the #pragma token syntax.

There are two levels of implementation in the run-time system. The actual interface between the producer and the run-time system is given by the standard tokens. The provided implementation defines these tokens in a way appropriate to itself. An alternative implementation would have to define the tokens differently. It is intended that the standard tokens are sufficiently generic to allow a variety of implementations to hook into the producer output in the manner they require.

2.6.1. Arithmetic types

The representations of the basic arithmetic types are target dependent, so, for example, an int may contain 16, 32, 64 or some other number of bits. Thus it is necessary to introduce a token to stand for each of the built-in arithmetic types (including the long long types). Each integral type is represented by a VARIETY token as follows:

Similarly each floating point type is represent by a FLOATING_VARIETY token:

Each integral type also has an encoding as a SIGNED_NAT as shown above. This number is a bit pattern built up from the following values:

Any target dependent integral type can be represented by a SIGNED_NAT token using this encoding. This representation, rather than one based on VARIETYs, is used for ease of manipulation. The token:

	~convert : ( SIGNED_NAT ) -> VARIETY

The token:

	~promote : ( SIGNED_NAT ) -> SIGNED_NAT

	#pragma TenDRA compute promote identifier

	#pragma TenDRA promoted type-id : promoted-type-id

The token:

	~arith_type : ( SIGNED_NAT, SIGNED_NAT ) -> SIGNED_NAT

Any tokenised type declared using:

	#pragma token VARIETY v # tv

So, for example, a sizeof expression has shape ~convert ( size_t ). The token ~cpp.bool is defined in the default implementation, but the other tokens are defined according to their definitions on the target machine in the normal API library building mechanism.

2.6.2. Integer literal types

The type of an integer literal is defined in terms of the first in a list of possible integral types. The first type in which the literal value can be represented gives the type of the literal. For small literals it is possible to work out the type exactly, however for larger literals the result is target dependent. For example, the literal 50000 will have type int on machines in which 50000 fits into an int, and long otherwise. This target dependent mapping is given by a series of tokens of the form:

	~lit_* : ( SIGNED_NAT ) -> SIGNED_NAT

Thus, for example, the shape of the integer literal 50000 is:

	~convert ( ~lit_int ( 50000 ) )

2.6.3. Bitfield types

The sign of a plain bitfield type, declared without using signed or unsigned, is left unspecified in C and C++. The token:

	~cpp.bitf_sign : ( SIGNED_NAT ) -> BOOL

2.6.4. Generic pointers

TDF has no concept of a generic pointer type, so tokens are used to defer the representation of void * and the basic operations on it to the target machine. The fundamental token is:

	~ptr_void : () -> SHAPE

The token:

	~null_pv : () -> EXP pv

	~to_ptr_void : ( ALIGNMENT a, EXP POINTER a ) -> EXP pv
	~from_ptr_void : ( ALIGNMENT a, EXP pv ) -> EXP POINTER a

	~pv_test : ( EXP pv, LABEL, NTEST ) -> EXP TOP
	~cpp.pv_compare : ( EXP pv, EXP pv, LABEL, NTEST ) -> EXP TOP

2.6.5. Undefined conversions

Several conversions in C and C++ can only be represented by undefined TDF. For example, converting a pointer to an integer can only be represented in TDF by forming a union of the pointer and integer shapes, putting the pointer into the union and pulling the integer out. Such conversions are tokenised. Undefined conversions not mentioned below may be performed by combining those given with the standard, well-defined, conversions.

The token:

	~ptr_to_ptr : ( ALIGNMENT a, ALIGNMENT b, EXP POINTER a ) -> EXP POINTER b

The tokens:

	~f_to_pv : ( EXP PROC ) -> EXP pv
	~pv_to_f : ( EXP pv ) -> EXP PROC

The tokens:

	~i_to_p : ( VARIETY v, ALIGNMENT a, EXP INTEGER v ) -> EXP POINTER a
	~p_to_i : ( ALIGNMENT a, VARIETY v, EXP POINTER a ) -> EXP INTEGER v
	~i_to_pv : ( VARIETY v, EXP INTEGER v ) -> EXP pv
	~pv_to_i : ( VARIETY v, EXP pv ) -> EXP INTEGER v

2.6.6. Integer division

The precise form of the integer division and remainder operations in C and C++ is left unspecified with respect to the sign of the result if either operand is negative. The tokens:

	~div : ( EXP INTEGER v, EXP INTEGER v ) -> EXP INTEGER v
	~rem : ( EXP INTEGER v, EXP INTEGER v ) -> EXP INTEGER v

2.6.7. Calling conventions

The function calling conventions used by the C++ producer are essentially the same as those used by the C producer with one exception. That is to say, all types except arrays are passed by value (note that individual installers may modify these conventions to conform to their own ABIs).

The exception concerns classes with a non-trivial constructor, destructor or assignment operator. These classes are passed as function arguments by taking a reference to a copy of the object (although it is often possible to eliminate the copy and pass a reference to the object directly). They are passed as function return values by adding an extra parameter to the start of the function parameters giving a reference to a location into which the return value should be copied.

Member functions

Non-static member functions are implemented in the obvious fashion, by passing a pointer to the object the method is being applied to as the first argument (or the second argument if the method has an extra argument for its return value).

Ellipsis functions

Calls to functions declared with ellipses are via the apply_proc TDF construct, with all the arguments being treated as non-variable. However the definition of such a function uses the make_proc construct with a variable parameter. This parameter can be referred to within the program using the ... expression. The type of this expression is given by the built-in token:

	~__va_t : () -> SHAPE

Note that the variable parameter is in effect only being used to determine where the first optional parameter is defined. The assumption is that all such parameters are located contiguously on the stack, however the fact that calls to such functions do not use the variable parameter mechanism means that this is not automatically the case. Strictly speaking this means that the implementation of ellipsis functions uses undefined behaviour in TDF, however given the non-type-safe function calling rules in C this is unavoidable and installers need to make provision for such calls (by dumping any parameters from registers to the stack if necessary). Given the theoretically type-safe nature of C++ it would be possible to avoid such undefined behaviour, but the need for C-compatible calling conventions prevents this.

2.6.8. Pointers to data members

The representation of, and operations on, pointers to data members are represented by tokens to allow for a variety of implementations. It is assumed that all pointers to data members (as opposed to pointers to function members) are represented by the same shape:

	~cpp.pm.type : () -> SHAPE

There are two basic methods of constructing a pointer to a data member. The first is to take the address of a data member of a class. A data member is represented in TDF by an expression which gives the offset of the member from the start of its enclosing compound shape (note that it is not possible to take the address of a member of a virtual base). The mapping from this offset to a pointer to a data member is given by:

	~cpp.pm.make : ( EXP OFFSET ) -> EXP pm

	~cpp.pm.null : () -> EXP pm

	~cpp.pm.offset : ( EXP pm, ALIGNMENT a ) -> EXP OFFSET ( a, a )

A pointer to a data member of a non-virtual base class can be converted to a pointer to a data member of a derived class. The reverse conversion is also possible using static_cast. If the base is a primary base class then these conversions are trivial and have no effect. Otherwise null pointers to data members are converted to null pointers to data members, and the non-null cases are handled by the tokens:

	~cpp.pm.cast : ( EXP pm, EXP OFFSET ) -> EXP pm
	~cpp.pm.uncast : ( EXP pm, EXP OFFSET ) -> EXP pm

The only remaining operations on pointer to data members are to test one against the null pointer to data member and to compare two pointer to data members. These are represented by the tokens:

	~cpp.pm.test : ( EXP pm, LABEL, NTEST ) -> EXP TOP
	~cpp.pm.compare : ( EXP pm, EXP pm, LABEL, NTEST ) -> EXP TOP

In the default implementation, pointers to data members are implemented as int. The null pointer to member is represented by 0 and the address of a class member is represented by 1 plus the offset of the member (in bytes). Casting to and from a derived class then correspond to adding or subtracting the base class offset (in bytes), and pointer to member comparisons correspond to integer comparisons.

2.6.9. Pointers to function members

As with pointers to data members, pointers to function members and the operations on them are represented by tokens to allow for a range of implementations. All pointers to function members are represented by the same shape:

	~cpp.pmf.type : () -> SHAPE

There are two basic methods for constructing a pointer to a function member. The first is to take the address of a non-static member function of a class. There are two cases, depending on whether or not the member function is virtual. The non-virtual case is given by the token:

	~cpp.pmf.make : ( EXP PROC, EXP OFFSET, EXP OFFSET ) -> EXP pmf

For virtual functions, a pointer to function member of the form above is entered in the virtual function table for the corresponding class. The actual pointer to the virtual function member then gives a reference into the virtual function table as follows:

	~cpp.pmf.vmake : ( SIGNED_NAT, EXP OFFSET, EXP, EXP ) -> EXP pmf

The second way of constructing a pointer to a function member is to use a null pointer to function member:

	~cpp.pmf.null : () -> EXP pmf
	~cpp.pmf.null2 : () -> EXP pmf

The cast operations on pointers to function members are more complex than those on pointers to data members. The value to be cast is copied into a temporary and one of the tokens:

	~cpp.pmf.cast : ( EXP ppmf, EXP OFFSET, EXP, EXP OFFSET ) -> EXP TOP
	~cpp.pmf.uncast : ( EXP ppmf, EXP OFFSET, EXP, EXP OFFSET ) -> EXP TOP

As with pointers to data members, there are tokens implementing comparisons on pointers to function members:

	~cpp.pmf.test : ( EXP ppmf, LABEL, NTEST ) -> EXP TOP
	~cpp.pmf.compare : ( EXP ppmf, EXP ppmf, LABEL, NTEST ) -> EXP TOP

The most important, and most complex, operation is calling a function through a pointer to function member. The first step is to copy the pointer to function member into a temporary. The token:

	~cpp.pmf.virt : ( EXP ppmf, EXP, ALIGNMENT ) -> EXP TOP

	~cpp.pmf.delta : ( ALIGNMENT a, EXP ppmf ) -> EXP OFFSET ( a, a )

	~cpp.pmf.func : ( EXP ppmf ) -> EXP PROC

The default implementation is that described in the ARM, where each pointer to function member is represented in the form:

	struct PTR_MEM_FUNC {
	    short delta ;
	    short index ;
	    union {
		void ( *func ) () ;
		short off ;
	    } u ;
	} ;

2.6.10. Class layout

Consider a class with no base classes:

	class A {
	    // A's members
	} ;

Two alternative ways of laying out the non-static data members within the class are implemented. The first, which is default, gives them in the order in which they are declared in the class definition. The second lays out the public, the protected, and the private members in three distinct sections, the members within each section being given in the order in which they are declared. The latter can be enabled using the -jo command-line option.

The offset of each member within the class (including vptr A) can be calculated in terms of the offset of the previous member. The first member has offset zero. The offset of any other member is given by the offset of the previous member plus the size of the previous member, rounded up to the alignment of the current member. The overall size of the class is given by the offset of the last member plus the size of the last member, rounded up using the token:

	~comp_off : ( EXP OFFSET ) -> EXP OFFSET

Classes with no members need to be treated slightly differently. The shape of such a class is given by the token:

	~cpp.empty.shape : () -> SHAPE

	~cpp.empty.offset : () -> EXP OFFSET

Bitfield members provide a slight complication to the picture above. The offset of a bitfield is additionally padded using the token:

	~pad : ( EXP OFFSET, SHAPE, SHAPE ) -> EXP OFFSET

The layout of unions is similar to that of classes except that all members have zero offset, and the size of the union is the maximum of the sizes of its members, suitably padded. Of course unions cannot be polymorphic and cannot have base classes.

Pointers to incomplete classes are represented by means of the alignment:

	~cpp.empty.align : () -> ALIGNMENT

2.6.11. Derived class layout

The description of the implementation of derived classes will be given in terms of the example class hierarchy given by:

	class A {
	    // A's members
	} ;

	class B : public A {
	    // B's members
	} ;

	class C : public A {
	    // C's members
	} ;

	class D : public B, public C {
	    // D's members
	} ;

Single inheritance

The layout of class A is given by:

Note that in theory two virtual function tables are required, the normal virtual function table for B, denoted by vtbl B, and a modified virtual function table for A, denoted by vtbl B::A, taking into account any overriding virtual functions within B, and pointing to B's run-time type information. This latter means that the dynamic type information for the A sub-object relates to B rather than A. However these two tables can usually be combined - if the virtual functions added in B are listed in the virtual function table after those inherited from A and the form of the overriding is suitably well behaved (in the sense defined below) then vptr B::A is an initial segment of vptr B. It is also possible to remove the vptr B field and use vptr B::A in its place in this case (it has to be this way round to preserve the A sub-object). Thus the items shaded in the diagram can be removed.

The class C is similarly given by:

Multiple inheritance

Class D is more complex because of the presence of multiple inheritance. D inherits all the members of B, including those which B inherits from A, plus all the members of C, including those which C inherits from A. It also inherits all of the virtual member functions from B and C, some of which may be overridden in D, extended by any additional virtual functions declared in D. This may be represented as follows:

The B base class of D is essentially similar to the single inheritance case already discussed; the C base class is different however. Note firstly that the C sub-object of D is located at a non-zero offset, delta D::C, from the start of the object. This means that the base class conversion from D to C consists of adding this offset (for pointer conversions things are further complicated by the need to allow for null pointers). Also vtbl D::C is not an initial segment of vtbl D because this contains the virtual functions inherited from B first, followed by those inherited from C, followed by those first declared in D (there are other reasons as well). Thus vtbl D::C cannot be eliminated.

Virtual inheritance

Virtual inheritance introduces a further complication. Now consider the class hierarchy given by:

	class A {
	    // A's members
	} ;

	class B : virtual public A {
	    // B's members
	} ;

	class C : virtual public A {
	    // C's members
	} ;

	class D : public B, public C {
	    // D's members
	} ;

The class C is similarly given by:

2.6.12. Constructors and destructors

The implementation of constructors and destructors, whether explicitly or implicitly defined, is slightly more complex than that of other member functions. For example, the constructors need to set up the internal vptr and ptr fields mentioned above.

The order of initialisation in a constructor is as follows:

1. The internal ptr fields giving the locations of the virtual base classes are initialised.
2. The constructors for the virtual base classes are called.
3. The constructors for the non-virtual direct base classes are called.
4. The internal vptr fields giving the locations of the virtual function tables are initialised.
5. The constructors for the members of the class are called.
6. The main constructor body is executed.

Note that similar steps to protect virtual base classes are not taken in an implicitly declared operator= function. The order of assignment in this case is as follows:

1. The assignment operators for the direct base classes (both virtual and non-virtual) are called.
2. The assignment operators for the members of the class are called.
3. A reference to the object assigned to (i.e. *this) is returned.

The order of destruction in a destructor is essentially the reverse of the order of construction:

1. The main destructor body is executed.
2. The destructor for the members of the class are called.
3. The internal vptr fields giving the locations of the virtual function tables are re-initialised.
4. The destructors for the non-virtual direct base classes are called.
5. The destructors for the virtual base classes are called.
6. If necessary the space occupied by the object is deallocated.

	delete this ;

The point at which the virtual function tables are initialised in the constructor, and the fact that they are re-initialised in the destructor, is to ensure that virtual functions called from base class initialisers are handled correctly (see ISO C++ 12.7).

A further complication arises from the need to destroy partially constructed objects if an exception is thrown in a constructor. A count is maintained of the number of base classes and members constructed within a constructor. If an exception is thrown then it is caught in the constructor, the constructed base classes and members are destroyed, and the exception is re-thrown. The count variable is used to determine which bases and members need to be destroyed.

These partial destructors currently do not interact correctly with any exception specification on the constructor. Exceptions thrown within destructors are not correctly handled either.

2.6.13. Virtual function tables

The virtual functions in a polymorphic class are given in its virtual function table in the following order: firstly those virtual functions inherited from its direct base classes (which may be overridden in the derived class) followed by those first declared in the derived class in the order in which they are declared. Note that this can result in virtual functions inherited from virtual base classes appearing more than once. The virtual functions are numbered from 1 (this is slightly more convenient than numbering from 0 in the default implementation).

The virtual function table for this class has shape:

	~cpp.vtab.type : ( NAT ) -> SHAPE

	~cpp.vtab.diag : () -> SHAPE

	~cpp.vtab.make : ( EXP pti, EXP OFFSET, NAT, EXP NOF ) -> EXP vt

The information given on each virtual function in this table has the form of a pointer to function member formed using the token:

	~cpp.pmf.make : ( EXP PROC, EXP OFFSET, EXP OFFSET ) -> EXP pmf

	~cpp.vtab.pure : () -> EXP PROC

To avoid duplicate copies of virtual function tables and run-time type information structures being created, the ARM algorithm is used. The virtual function table and run-time type information structure for a class are defined in the module containing the definition of the first non-inline, non-pure virtual function declared in that class. If such a function does not exist then duplicate copies are created in every module which requires them. In the former case the virtual function table will have an external tag name; in the latter case it will be an internal tag. This scheme can be overridden using the -jv command-line option, which causes local virtual function tables to be output for all classes.

Note that the discussion above applies to both simple virtual function tables, such as vtbl B above, and to those arising from base classes, such as vtbl B::A. We are now in a position to precisely determine when vtbl B::A is an initial segment of vtbl B and hence can be eliminated. Firstly, A must be the first direct base class of B and cannot be virtual. This is to ensure both that there are no virtual functions in vtbl B before those inherited from A, and that the corresponding base class conversion is trivial so that the pointers to function members of B comprising the virtual function table can be equally regarded as pointers to function members of A. The second requirement is that if a virtual function for A, f, is overridden in B then the return type for B::f cannot differ from the return type for A::f by a non-trivial conversion (recall that ISO C++ allows the return types to differ by a base class conversion). In the non-trivial conversion case the function entered in vtbl B::A needs to be, not B::f as in vtbl B, but a stub function which calls B::f and converts its return value to the return type of A::f.

Calling virtual functions

The virtual function call mechanism is implemented using the token:

	~cpp.vtab.func : ( EXP ppvt, SIGNED_NAT ) -> EXP ppmf

	~cpp.pmf.delta : ( ALIGNMENT a, EXP ppmf ) -> EXP OFFSET ( a, a )
	~cpp.pmf.func : ( EXP ppmf ) -> EXP PROC

2.6.14. Run-time type information

Each C++ type can be associated with a run-time type information structure giving information about that type. These type information structures have shape given by the token:

	~cpp.typeid.type : () -> SHAPE

	~cpp.typeid.make : ( SIGNED_NAT, EXP, EXP ) -> EXP ti

	~cpp.baseid.type : () -> SHAPE

	~cpp.baseid.make : ( EXP, EXP, EXP, SIGNED_NAT, SIGNED_NAT ) -> EXP bi

The following table gives the various tag numbers used in type information structures plus a list of the base type information structures associated with each type. Macros giving these tag numbers are provided in the default implementation in a header, interface.h, which is shared by the C++ producer.

In the form column cv T is used to denote not only the normal cv-qualifiers but, when T is a function type, the member function cv-qualifiers. Arrays with an unspecified bound are treated as if their bound was zero. Functions with ellipsis are treated as if they had an extra parameter of a dummy type named ... (see below). Note the distinction between C++ and C function types.

Each base type information structure is described as a triple consisting of a type and two integers. One of these integers may be used to encode a type qualifier, cv, as follows:

The base type information for a class consists of information on each of its direct base classes. The includes the offset of this base within the class (for a virtual base class this is the offset of the corresponding ptr field), whether the base is virtual (1) or not (0), and the base class access, encoded as follows:

For example, the run-time type information structures for the classes declared in the diamond lattice above can be represented as follows:

Defining run-time type information structures

For built-in types, the run-time type information structure may be referenced by the token:

	~cpp.typeid.basic : ( SIGNED_NAT ) -> EXP pti

Note that the encoding for the basic integral types is the same as that given above. The other types are assigned to unused values. Note that the encodings for ptrdiff_t and size_t are not used, instead that for their implementation is used (using the standard tokens ptrdiff_t and size_t). The encodings for bool and wchar_t are used because they are conceptually distinct types even though they are implemented as one of the basic integral types. The type labelled ... is the dummy used in the representation of ellipsis functions. The default implementation uses an array of type information structures, __TCPPLUS_typeid, to implement ~cpp.typeid.basic.

The run-time type information structures for classes are defined in the same place as their virtual function tables. Other run-time type information structures are defined in whatever modules require them. In the former case the type information structure will have an external tag name; in the latter case it will be an internal tag.

Accessing run-time type information

The primary means of accessing the run-time type information for an object is using the typeid construct. In cases where the operand type can be determined statically, the address of the corresponding type information structure is returned. In other cases the token:

	~cpp.typeid.ref : ( EXP ppvt ) -> EXP pti

Another means of querying the run-time type information for an object is using the dynamic_cast construct. When the result cannot be determined statically, this is implemented using the token:

	~cpp.dynam.cast : ( EXP ppvt, EXP pti ) -> EXP pv

2.6.15. Dynamic initialisation

The dynamic initialisation of variables with static storage duration in C++ is implemented by means of the TDF initial_value construct. However in order for the producer to maintain control over the order of initialisation, rather than each variable being initialised separately using initial_value, a single expression is created which initialises all the variables in a module, and this initialiser expression is used to initialise a single dummy variable using initial_value. Note that, while this enables the variables within a single module to be initialised in the order in which they are defined, the order of initialisation between different modules is unspecified.

The implementation needs to keep a list of those variables with static storage duration which have been initialised so that it can call the destructors for these objects at the end of the program. This is done by declaring a variable of shape:

	~cpp.destr.type : () -> SHAPE

	~cpp.destr.global : ( EXP pd, EXP POINTER c, EXP PROC ) -> EXP TOP

The implementation also needs to ensure that it calls the destructors in this list at the end of the program, including calls of exit. This is done by calling the token:

	~cpp.destr.init : () -> EXP TOP

	~cpp.start : () -> EXP TOP

2.6.16. Exception handling

Conceptually, exception handling can be described in terms of the following diagram:

Provided no exception is thrown this stack grows and shrinks in a well-behaved manner as execution proceeds. When an exception is thrown an exception manager is invoked to find a matching exception handler. The exception manager proceeds to execute a loop to unwind the stack as follows. If the stack is empty then the exception cannot be caught and std::terminate is called. Otherwise the top element is popped from the stack. If this is a local variable then the associated destructor is called for the variable. If the top element is a try block then the current exception is compared in turn to each of the associated handlers. If a match is found then execution jumps to the handler body, otherwise the exception manager continues to the next element of the stack.

Note that this description is purely conceptual. There is no need for exception handling to be implemented by a stack in this way (although the default implementation uses a similar technique). It does however serve to illustrate the various stages which must exist in any implementation.

Try blocks

At the start of a try block a variable of shape:

	~cpp.try.type : () -> SHAPE

	~cpp.try.begin : ( EXP ptb, EXP POINTER fa, EXP POINTER ca ) -> EXP TOP

When control exits from a try block, whether by reaching the end of the block or jumping out of it, the block is removed from the stack using the token:

	~cpp.try.end : ( EXP ptb ) -> EXP TOP

Local variables

The technique used to add a local variable with a non-trivial destructor to the stack is similar to that used in the dynamic initialisation of global variables. A local variable of shape ~cpp.destr.type is declared at the start of the variable scope. This is initialised just after the constructor for the variable is called using the token:

	~cpp.destr.local : ( EXP pd, EXP POINTER c, EXP PROC ) -> EXP TOP

	~cpp.destr.end : ( EXP pd ) -> EXP TOP

In cases where the local variable may be conditionally initialised (for example a temporary variable in the second operand of a || operation) the local variable of shape ~cpp.destr.type is initialised to the value given by the token:

	~cpp.destr.null : () -> EXP d

	~cpp.destr.ptr : ( EXP pd ) -> EXP POINTER c

Throwing an exception

When a throw expression with an argument is encountered a number of steps performed. Firstly, space is allocated to hold the exception value using the token:

	~cpp.except.alloc : ( EXP VARIETY size_t ) -> EXP pv

	~cpp.except.throw : ( EXP pv, EXP pti, EXP PROC ) -> EXP BOTTOM

A throw expression without an argument results in a call to the token:

	~cpp.except.rethrow : () -> EXP BOTTOM

Handling an exception

The exception manager proceeds to find an exception in the manner described above, unwinding the stack and calling destructors for local variables. When a try block is popped from the stack a TDF long_jump is applied to transfer control to its list of handlers. For each handler in turn it is checked whether the handler can catch the current exception. For ... handlers this is always true; for other handlers it is checked using the token:

	~cpp.except.catch : ( EXP pti ) -> EXP VARIETY int

If an exception is caught by a handler then a number of steps are performed. Firstly, if appropriate, the handler variable is initialised by copying the current exception value. A pointer to the current exception value can be obtained using the token:

	~cpp.except.value : () -> EXP pv

	~cpp.except.caught : () -> EXP TOP

	~cpp.except.end : () -> EXP TOP

To conclude, the TDF generated for a try block and its associated list of handlers has the form:

	variable (
	    long_jump_access,
	    stack_tag,
	    make_value ( ~cpp.try.type ),
	    conditional (
		handler_label,
		sequence (
		    ~cpp.try.begin (
			obtain_tag ( stack_tag ),
			current_env,
			make_local_lv ( handler_label ) ),
			try-block-body,
			~cpp.try.end ),
		    conditional (
			catch_label_1,
			sequence (
			    integer_test (
				not_equal,
				catch_label_1,
				~cpp.except.catch (
				    handler-1-typeid ) )
			    variable (
				handler_tag_1,
				handler-1-init (
				    ~cpp.except.value ),
				sequence (
				    ~cpp.except.caught,
				    handler-1-body ) )
			    ~cpp.except.end )
			conditional (
			    catch_label_2,
			    further-handlers,
			    ~cpp.except.rethrow ) ) ) )

Note that for a local variable to maintain its previous value when an exception is caught in this way it is necessary to declare it using the TDF long_jump_access construct. Any local variable which contains a try block in its scope is declared in this way.

To aid implementations in the writing of exception managers the following standard tokens are provided:

	~cpp.ptr.code : () -> SHAPE POINTER ca
	~cpp.ptr.frame : () -> SHAPE POINTER fa
	~cpp.except.jump : ( EXP POINTER fa, EXP POINTER ca ) -> EXP BOTTOM

Exception specifications

If a function is declared with an exception specification then extra code needs to be generated in the function definition to catch any unexpected exceptions thrown by the function and to call std::unexpected . Since this is a potentially high overhead for small functions, this extra code is not generated if it can be proved that such unexpected exceptions can never be thrown (the analysis is essentially the same as that in the exception analysis check).

The implementation of exception specification is to enclose the entire function definition in a try block. The handler for this block uses ~cpp.except.catch to check whether the current exception can be caught by any of the types listed in the exception specification. If so the current exception is re-thrown. If none of these types catch the current exception then the token:

	~cpp.except.bad : ( SIGNED_NAT ) -> EXP TOP

2.6.17. Mangled identifier names

In a similar fashion to other C++ compilers, the C++ producer needs a method of mapping C++ identifiers to a form suitable for further processing, namely TDF tag names. This mangled name contains an encoding of the identifier name, its parent namespace or class and its type. Identifiers with C linkage are not mangled. The producer contains a built-in name unmangler which performs the reverse operation of transforming the mangled form of an identifier name back to the underlying identifier. This can be useful when analysing system linker errors.

Note that the type of an identifier forms part of its mangled name not only for functions, but also for variables. Many other compilers do not mangle variable names, however the ISO C++ rules on namespaces and variables with C linkage make it necessary (this can be suppressed using the -j-n command-line option). Declaring the language linkage of a variable inconsistently can therefore lead to linking errors with the C++ producer which are not detected by other compilers. A common example is:

	extern int errno ;

	extern "C" int errno ;

As described above, the mangled form of an identifier has three components; the identifier name, the identifier namespace and the identifier type. Two underscores (__) are used to separate the name component from the namespace and type components. The mangling scheme used is based on that described in the ARM. The description below is not complete; the mangling and unmangling routines themselves should be consulted for a complete description.

Mangling identifier names

Simple identifier names are mapped to themselves. Unicode characters of the forms \uxxxx and \Uxxxxxxxx are mapped to __kxxxx and __Kxxxxxxxx respectively, where the hex digits are output in their canonical lower-case form. Constructors are mapped to __ct and destructors to __dt. Conversions functions are mapped to __optype where type is the mangled form of the conversion type. Overloaded operator functions, operator@, are mapped as follows:

Note that this table contains a number of operators which are not part of C++ or cannot be overloaded in C++. These are used in the representation of target dependent integer constants.

Mangling namespace names

The global namespace is mapped to an empty string. Simple namespace and class names are mapped as above, but are preceded by a series of decimal digits giving the length of the mangled name. Nested namespaces and classes are represented by a sequence of such namespace names, preceded by the number of elements in the sequence. This takes the form Qdigit if there are less than 10 elements, or Q_digits_ if there are more than 10. Note that members of anonymous classes or namespaces are local to their translation unit, and so do not have external tag names.

Mangling types

The mangling of types is essentially similar to that used in the symbol table dump format. The type used in the mangled name for an identifier ignores the return type for a function and ignores the most significant bound for an array.

The built-in types are mapped in precisely the same way as in the symbol table dump. Class and enumeration types are mapped to their type names mangled in the same way as the namespace names above. The exception to this is that in a class member, the parent class is mapped to X.

The composite types are again mapped in a similar fashion to that in the dump file. For example, PCc represents const char *. The only difficult case concerns function parameter types where the ARM T and N encodings are used for duplicate parameter types. The function return type is included in the mangled form except for function identifier types. In the cases where the identifier is known always to represent a function (constructors, destructors etc.) the initial F indicating a function type is also omitted.

The types of template functions and classes are represented by the underlying template and the template arguments giving rise to the instance. Template classes are preceded by t; template functions are preceded by G rather than F. Type arguments are represented by Z followed by the type value; non-type arguments are represented by the argument type followed by the argument value. In the underlying type the template parameters are represented by m0, m1 etc. An alternative scheme, in which the mangled form of a template function includes the type of that instance, rather than the underlying template, can be enabled using the -j-f command-line option.

Other mangled names

The virtual function table for a class, when this is a variable with external linkage, is named __vt__type , where type is the mangled form of the class name. The virtual function table for a base class is named __vt__base where base is a sequence of mangled class names specifying the base class. The run-time type information structure for a type, when this is a variable with external linkage, is named __ti__type, where type is the mangled form of the type name.

Mangled name examples

The following gives some examples of the name mangling scheme:

	class A {
	    static int a ;			// a__1Ai
	public :
	    A () ;				// __ct__1A
	    A ( int ) ;				// __ct__1Ai
	    A ( const A & ) ;			// __ct__1ARCX
	    virtual ~A () ;			// __dt__1A
	    operator bool () ;			// __opb__1A
	    bool operator! () ;			// __nt__1A
	} ;

	// virtual function table	__vt__1A
	// run-time type information	__ti__1A

	int f ( A *, int, A * ) ;		// f__FP1AiT1
	int b = 2 ;				// b__i
	int c [3] ;				// c__A_i

	namespace N {
	    int *p = 0 ;			// p__1NPi
	}

Part of the TenDRA Web.
Crown Copyright © 1998.