How does xctocc work?

For each C++ class c, xctocc generates a class os_c. Object of this new class contain an extra pointer back to the Scheme representation of the object, and the Scheme representation has a pointer to the C++ object.

For each method of the class, xctocc generates a Scheme-to-C++ glue function which is installed into the Scheme representation of the class. This glue function takes Scheme parameters, checks that they are the right number and type (and, for overloaded methods, chooses an version of the method based on the number and type or arguments), and then unbundles the Scheme data into C++ data to call the ``real'' method. The return value of the ``real'' method is then bundled into a Scheme value and returned by the glue function.

The Scheme-to-C++ glue function receives Scheme parameters in an array p, with an array size n. The ith C++ method parameter is unbundled into the variable xi.

When a C++ method is virtual in the class c, then the os_c class overrides the method. The os_c method checks the Scheme representation for an overriding method in the Scheme world; if none is found, then the c version of the method is called. Otherwise, the os_c method acts as C++-to-Scheme glue: C++ values are bundled into Scheme values and the Scheme method is called; the return value of the Scheme method is unbundled and passed back as the result of the os_c method. Special handling keeps Scheme exceptions from jumping out of the os_c method.

The same variable names are used in the C++-to-Scheme glue as in the Scheme-to-C++ glue; p contains the array of Scheme parameters, which are bundled from the xi input C++ variables.

When a C++ class d inherits a non-virtual method from a class c, then the method needs to be declared in an ``.xc'' script only for the superclass. If d overrides a method, then the method must be declared in a script for d. When a method is virtual, it must be declared in a script for every class that could override the method, even if the derived class in C++ does not actually override the virtual function. This requirement clearly follows from the implementation described above.

For global functions, xctocc simply generates a Scheme-to-C++ glue function and installs it as a global ``primitive'' function in the Scheme world.

For most C++ data types, bundling and unbundling is simple. Objects are handled specially: for each class, xctocc generates an object bundler and unbundler that can access the appropriate pointer stored in an os_c object. A hash table is used to determine whether an object in class c is actually an os_c object. If the object (nomally from class c) is actually form a class d derived from c, then it can be bundled into a Scheme d% object only if sufficient dynamic type information is available.

It would be difficult for xctocc to automatically bundle and unbundle all possible C++ data types. When a parameter or return type is not one of the types built into xctocc, the programmer must provide bundling and unbundling code in the form of xctocc macros.