| 
| 10 C++ translator |
| 
| 10.2 Activating the C++ translator |
|
| 10.1 Introduction |
10.1 Introduction
The C++ translator was developed by Univan Ahn [6].
The C++ translator is based heavily on the translator developed for
the original RAISE tools by Jesper Gørtz, Jan Reher, Henrik Snog,
and Eld Zierau of Cap Programator. We are grateful for their
permission to reuse their work.
We use the term RSLC++ for the subset of RSL that is accepted
by the the translator. RSLC++ excludes object arrays,
channels, axioms, abstract types, union types, implicit value and
function definitions. It only includes quantified expressions,
comprehended expressions, implicit let expressions, and local expressions if
they conform to the rules given below in
sections 10.8.12, 10.8.7,
10.8.24, and 10.8.23. It includes overloading
of names only if they conform to the rules of
overloading of C++: overloaded identifiers must be the names of
functions with distinguishable parameter types.
The translator has to generate some names, and these always include
somewhere the string "rsl" (where some letters may be upper case).
So RSLC++ does not include identifiers containing this
string.
Neither does it contain identifiers that are C++ keywords, nor names
involving double underscores.
The term universal types is used for some generated C++ types. See
section 10.12 on universal
types.
The translator produced code has been tested with the Free Software
Foundation's GNU C++ compiler g++ version 2.95.2. It is
intended to conform to the ANSI C++ standard and so should work with
other compilers.
The translator has been run under Solaris, Linux and Windows 9X and
NT, and the C++ output compiled and run under these operating systems.
The translator has also been used with Microsoft's Visual C++
compiler, version 6.0. This causes some difficulty, especially with
the use of overloaded template functions. It is thought that
most problems have been resolved.
The following lists mention known errors and problems and a few
desirable extensions. Other problems and wishes will undoubtedly
emerge from the use of the translator. It is worth noting that many of
these problems also arise on manual translation from RSL to C++, and
that the problems, with the exception of those concerning Int and
Real, are easily avoided.
- C++ compilers seem not to accept nested namespaces with the same
names. So an object A, say, should not contain an object
also called A. This is easily avoided with some manual renaming
of objects.
- The arithmetic types Int (including Nat) and Real
are naively translated into int and double without regard for actual
limits and precision. Float-integral conversions and the results of
integer divide and modulo applied to negative operands are also
implementation dependent. And so is the use of arithmetic exceptions
on overflow and division by zero.
- In RSL the initial value of a variable declared without initialisation is underspecified
within its type. The corresponding variable in C++ will be uninitialised.
- Map enumeration is treated by the translator by means of override instead of union, that
way disregarding any possibly resulting non-determinism.
- The translation relies heavily on the syntactic form of the
input, which means that often a semantically equivalent piece of RSL
text cannot be translated or is translated differently. For
example, a record or variant type is accepted, but the equivalent
expansion into a sort, some value signatures, and some axioms is not
accepted.
- Separate compilation is not currently supported. Running the
translator on a number of RSL modules generates one header
.h file and one body .cc or .cpp file.
- The use of templates with Microsoft's Visual C++ causes
problems. There is an option to translate for this compiler, which
greatly reduces the use of templates.
Chris George, April 17, 2008
| 10.1 Introduction |
| |
| 10 C++ translator |
| |
| 10.2 Activating the C++ translator |
|