PART 19 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 (128.195.1.1) 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 (128.230.7.14) 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 copy-initialization. - The `overload' keyword was made redundant and removed to the anachronism section. - 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.