Re: Finding objects on C stack - alternate GCPRO

[Stephen J. Turnbull]

Richard Stallman writes:

 > Please don't make Emacs use C++.  C++ is an ugly and clumsy language.

Except where it isn't.

XEmacs code is required to compile with both C (specifically C89,
thought there has been discussion recently of preferring C99) and C++
(IIRC this dialect was named "Clean C" by Martin Buchholz).  This has
two advantages in our practice: (1) the stricter typing rules of C++
catch some bugs[1], and (2) some things that are impossible to express
cleanly in C (specifically, typeof(Emacs character) != EMACS_INT,
which has been very useful in completely preventing certain Mule bugs
that have regressed frequently in Emacs's implementation) can be
implemented in the C++ build, and therefore type-checked.

Granted, the code needed to implement such a type in C++ is very
redundant if not specifically ugly, but it's really a unit test for a
"unit" that pervades text manipulation code rather than being
modularized into a few files.  It's nice if test code can be clean and
pretty, but when necessary I don't have a problem with gymnastics in
test code.  On the other hand, the code that actually implements
XEmacs functionality still compiles (and works correctly! :-) with C
and "typedef EMACS_INT Ichar" (where Ichar is our typedef for the
internal representation of the character type).

If C++ makes it possible to write *functionally better* allocation and
garbage collection code in a clean and intelligible way, I would be in
favor of relaxing the prohibition of C++ for *specified* files and
*specified* C++ idioms.

Footnotes: 
[1]  I don't know if this is still true for the most recent, tighter C
standard, but in our code --std=C99 does not catch all the common bugs
that a C++ build does.