C++ : Nuances of particular implementations


Q124: Why don't variable arg lists work for C++ on a Sun SPARCstation?

A: That is a bug in cfront 2.1.  There is a magic variable, __builtin_va_alist.
It has to be added to the end of the argument list of a varadic function, and
it has to be referenced in va_start.  This requires source modification to (a)
print `,__builtin_va_alist' on the end of the argument list, (b) pretend that
this arg was declared, and thus pass references to it, and (c) not mangle its
name in the process.

Here's a tiny bit more detail:
1) when print2.c prints a varadic procedure, it should add __builtin_va_alist
   to the end. It need not declare it. Type of int to the Sun C compiler (the
   default) is fine.
2) #define   va_start(ap,parmN)   ap = (char *)&__builtin_va_alist
3) when find.c see this reference to __builtin_va_alist, it should construct a
   special cfront name node. When name::print sees that node it should print
   its name literally, without adding any mangling.
4) the same trick is needed, with the name va_alist, for Ultrix/MIPS and HPUX.
5) the net result, in generated C code, looks like:
	void var_proc (a, b, c, __builtin_va_alist)
	  int a;
	  float b;
	  char * c;
	    char * val;
	    val = &__builtin_va_alist;

Q124: GNU C++ (g++) produces big executables for tiny programs; Why?
A: libg++ (the library used by g++) was probably compiled with debug info (-g).
On some machines, recompiling libg++ without debugging can save lots of disk
space (~1 Meg; the down-side: you'll be unable to trace into libg++ calls).
Merely `strip'ping the executable doesn't reclaim as much as recompiling
without -g followed by subsequent `strip'ping the resultant `a.out's.

Use `size a.out' to see how big the program code and data segments really are
rather than `ls -s a.out' which includes the symbol table.

Q126: Is there a yacc-able C++ grammar?
A: Jim Roskind is the author of a yacc grammar for C++. It's roughly compatible
with the portion of the language implemented by USL cfront 2.0.  Jim's grammar
deviates from cfront (and the ARM) in a couple of what I understand to be minor
ways.  Ultimately any deviation from a standard is unthinkable, but the number
of real programs that are interpreted differently is relatively small, so the
`consequence' of the deviation is not great.

I have used Jim's grammar when a grad student wrote a C++ templatizer mechanism
(reads ANSI-C++, spits out pre-templates C++), but my expertise does not
include precise knowledge of where the grammar deviates from `official'.  I
have found it to parse most things correctly, but I am aware that there are
differences.  (is that noncommittal enough? :-)

The grammar can be accessed by anonymous ftp from the following sites:
* ics.uci.edu ( in the ftp/gnu directory (even though
  neither of the archives are GNU related) as:
        c++grammar2.0.tar.Z and byacc1.8.tar.Z
* mach1.npac.syr.edu ( in the ftp/pub/C++ directory as:
        c++grammar2.0.tar.Z and byacc1.8.tar.z

Jim Roskind can be reached at jar@hq.ileaf.com or  ...!uunet!leafusa!jar

Q127: What is C++ 1.2?  2.0?  2.1?  3.0?
A: These are not versions of the language, but rather versions of the USL
translator, cfront.  However many people discuss these as levels of the
language as well, since each of the above versions represents additions to the
portion of the C++ language which is implemented by the compiler. When ANSI/ISO
C++ is finalized, conformance with the ANSI/ISO spec will become more important
than conformance with cfront version X.Y, but presently, cfront is acting as a
de facto standard to help coordinate the industry (although it leaves certain
features of the language unimplemented as well).

*VERY* roughly speaking, these are the major features:
 * 2.0 includes multiple/virtual inheritance and pure virtual functions.
 * 2.1 includes semi-nested classes and `delete [] ptr_to_array'.
 * 3.0 includes fully-nested classes, templates and `i++' vs `++i'.
 *?4.0? will include exceptions.

Q128: How does the lang accepted by cfront 3.0 differ from that accepted by 2.1?
A: USL cfront release 3.0 provides implementations of a number of features that
were previously flagged as `sorry not implemented':

  templates, fully nested types, prefix and postfix increment and decrement
  operators, initialization of single dimension arrays of class objects with
  ctors taking all default arguments, use of operators &&, ||, and ?: with
  expressions requiring temporaries of class objects containing destructors,
  and implicit named return values.

The major feature not accepted by cfront 3.0 is exceptions.

Q129: Why are exceptions going to be implemented after templates? Why not both?
A: Most C++ compiler vendors are providing templates in their present release,
but very few are providing exceptions (I know of only one).  The reason for
going slowly is that both templates and exception handling are difficult to
implement *well*. A poor template implementation will give slow compile and
link times and a poor exception handling implementation will give slow run
times.  Good implementations will not have those problems.

C++ compiler vendors are human beings too, and they can only get so much done
at once.  However they know that the C++ community is craving for the `whole'
language, so they'll be pushing hard to fill that need.

Q130: What was C++ 1.xx, and how is it different from the current C++ language?
A: C++ 1.2 (the version number corresponds to the release number of USL's
cfront) corresponds to Bjarne Stroustrup's first edition (`The C++ Programming
Language', ISBN 0-201-12078-X).  In contrast, the present version (3.0)
corresponds roughly to the `ARM', except for exceptions.  Here is a summary of
the differences between the first edition of Bjarne's book and the ARM:
 - A class can have more than one direct base class (multiple inheritance).
 - Class members can be `protected'.
 - Pointers to class members can be declared and used.
 - Operators `new' and `delete' can be overloaded and declared for a class.
     This allows the "assignment to `this'" technique for class specific
     specific storage management to be removed to the anachronism section
 - Objects can be explicitly destroyed.
 - Assignment and Copy-Initialization default to member-wise assignment and
 - The `overload' keyword was made redundant and removed to the anachronism
 - General expressions are allowed as initializers for static objects.
 - Data objects can be `volatile' (new keyword).
 - Initializers are allowed for `static' class members.
 - Member functions can be `static'.
 - Member functions can be `const' or `volatile'.
 - Linkage to non-C++ program fragments can be explicitly declared.
 - Operators `->', `->*' and `,' can be overloaded.
 - Classes can be abstract.
 - Prefix and postfix application of `++' and `--' on a user-defined type
     can be distinguished.
 - Templates.
 - Exception handling.