Proposal 95-04: for scanner output to be in the form of macros rather than end C++ code.

Jonathan Poole

A postscript version of this whole document is available here

The latex source is available here

This proposal suggests a set of rules for the output of the scanner. It is phrased in terms of outputting macros, so that statements about the behaviour of the library do not need to be made too early. In addition by keeping the insertions as small as possible, the hope is that the structure of the code is changed as little as possible.

See also proposal 95-02 where changes are suggested to the way that asynchronous function calling is signalled, that means that parameter lists woldn't need to be adjusted by the scanner. In addition, per Proposal 95-01, if activenew is removed, then the scanner doesn't need to do anything about them. Indeed it appears that everything can (probably) be done using just the insertion of redirector macros to the beginning of each member function/operator, and the specification of a common base class for all UC++ objects.

Class Declarations

All UC++ classes (that is, ones whose source is seen by the scanner) have fields inserted to store the virtual processor id of the object. There are two ways this information might be included:

See Proposal 95-03 which argues that such extra information should be included using inheritance. In such a case all that needs to be added is:

class MyClass : virtual UCPP {

This might be added by the scanner, though my preference would be for the programmer to add this to manually to classes that they want to be UC++ classes. The scanner would then have to keep track of which classes these are and only add redirectors to these classes.

Member Function

All member functions need to have redirectors, that check if the object is local, and if not package up all the parameters and send them and the function name off to the processor holding the object. All the implementation details of this can be hidden behind a single macro call in each member function, as follows:

For a function with the following properties:

a redirector is inserted as follows, where Symbol is a unique symbol generated for each member function, such that it is the same for the corresponding redirector and external hook function.


and an external function generator is output as follows:


so that for example

MyClass::Func(int i, Other O)
// stuff in member function


MyClass::Func(int i, Other O)
//                                           ^^ 
//                                       unique number
// stuff in member function

with at file scope


Because the means of indicating that member functions should be asynchronous must be changed so that it is not signalled using the parameter lists, there is no need to change the class declaration of member functions, unless they are defined inline.

[Note that it should be possible, if we use name mangling to call directly to the member functions and avoid the production of the external function hooks. All the information is available in the redirector macro to allow the run-time symbol name of the member function to be determined. Not clear though if it would be worth the trouble.]

Constructors and Destructors

Since the placement information can be moved to the placement new operator (see Proposal 95-01) the constructor can actually be dealt with substantially as other member functions, though it does not have a return type.

More thought needed on this part, to be clear about the C++ object model---when constructors get called and so on. Should try to deal correctly with objects allocated statically.


Can be dealt with in an analogous way to member functions, though there will probably have to be a macro for each overloadable member operator.

Public member data objects

Are a problem.

Jonathan Poole
Wed Aug 2 17:53:56 BST 1995