Charles Levert wrote:
> The Linux Kernel Mailing List FAQ already addresses C vs C++. Linux
> and Plex86 are two, but then again, both are system programming.
> Reading that part of the FAQ is instructive in the context of this
> discussion.
>
> http://www.tux.org/lkml/index.html#s1-4
>
> Charles
Another spin on the issue:
I would advocate using C++ at *least* as "a better C". Maybe even use
"light-weight" classes: They would provide a convenient means to bundle
structs and functions - but we would have to avoid implicit constructors
and destructors (explicit is fine), no multiple inheritance (and
probably not even single inheritance), no C++ exceptions, no virtual
functions (and thus no vtables), and certainly no RTTI. This means that
STL and similar class libraries are gone as well.
What does that leave? Quite a bit, actually:
1. Stronger compile-time checking. Stronger type checking in
particular, especially when common elements are wrapped in light-weight
classes (think of it as less pointer math).
2. Code generation on par with C. Once you eliminate all the expensive
and complex doo-dads, a mildly restricted subset of C++ can be quite
effective and efficient. You can even disable name-mangling (especially
if you avoid C++ inheritance), and obtain direct C linkage for free.
3. You still get templates! You have to be careful, but simple
templates can strike the perfect balance between cookie-cutter code,
rampant casting, and ponderous #define functions.
I participated (mainly as a kibitzer) in the early "EC++" (Embedded C++)
standardization effort (which, BTW, is compiled by g++). This was an
effort spearheaded (and funded) by several large Japanese companies
intent on improving productivity and reliability in embedded software
development. A similar group developed the uITRON RTOS, which is found
in everything from VCRs to cars. P.J. Plaugher, of Dinkumware Software
(and also a long time tech author and columnist), wrote an amazing set
of EC++ class libraries that are not only light-weight, but are also
ROMable!
It will be some time before writing EC++ becomes common, or even well
known. I am not aware of it being taught in any schools, nor am I aware
of any books in English on the subject. Learning it requires that you
forget many of the "wonderful" aspects of C++, and focus exclusively on
the effective, efficient and useful features.
>From my minor glance at the Plex86 code base, it may be worth the effort
to do the "cleanup" needed to make it palatable to g++. This will allow
new Plex86 capabilities to be prototyped and tested in EC++. Once the
basic concept is developed and proven, it can still be implemented in
clean C, keeping the C++ as comments in the C code. (I can envision a
Perl script that will bounce a file between the two code versions...)
The day will come when the C and EC++ versions of the code will differ
by a single-digit percentage in both size and execution time. When that
day does come, it will mean at least two things:
1. (E)C++ compilers (well, g++) are getting "good enough" for systems
work.
2. People will have learned to use the most effective parts of C++, and
exclude the bloat.
In the mean time, some or all of the C code that is "C++ compatible"
(well, "g++ compatible" at least) can still be compiled with gcc as long
as any meaningful performance differences or excessive bloat exists
(since my gcc and g++ are both egcs, there is no difference on my
system). Where no significant difference exists, that code can be
"committed" to g++.
While this may sound like a lot of work, only the "cleanup" will affect
the entire code base, and I don't think it will be at all drastic
(again, I have only taken a quick look, and have not actually tried to
feed the Plex86 code to g++). After that, it will be up to the C++
zealots to PROVE their code is as good as C. I suspect Kevin will then
(and ONLY then) be willing to consider committing (E)C++ code into the
Plex86 CVS.
So, how about a middle path? Make Plex86 "g++ clean" (and use g++ where
it makes no difference). This will give the C++ folks the incentive to
learn EC++ (or whatever subset of C++ is truly effective), and the
ability to do transparent (E)C++ development for Plex86. Commits of
C++ code can and should only happen when the result is on par with the C
code.
This also means that the C++ folks will have to write two versions of
their code. If they want to, why not let them? Let's say they
eventually meet the "C standard" for code size and speed (within the
bounds seen with normal C programmers). We would then be fools not to
switch to EC++ (at least for future development) and gain the distinct
advantages that language provides over C. Since EC++ is much simpler
than C++, it will not represent much of a hurdle for any experienced C
programmer who has taken at least one C++ class (or is willing to read
Al Steven's book on the subject).
Plex86 is still young enough (and small enough) that making it "g++
compatible" now is a relatively small effort (compared to, say, the
Linux kernel). Why not do so? If EC++ never becomes "good enough",
little will be lost. But if (when) EC++ (g++, and our ability to use it
properly) does finally get there, well, I see no downside at all!
Could Plex86 then become be the first major "system level" C++ Linux
application? (Are there already some I'm not aware of?) Why not open
the door to the possibility?
There are additional advantages inherent in EC++ that spring from using
an OO language, rather than enforcing OO discipline on a non-OO
language. For more information, try these links:
A magazine article on EC++ (in PDF):
http://www.dedicated-systems.com/magazine/99q1/1999q1_p090.pdf
A student paper giving an EC++ overview:
http://www.niksula.cs.hut.fi/~ttaalas/ecpp.htm
P.J. Plaugher on EC++:
http://www.dinkumware.com/embed9710.html
The "Home" of EC++ (a seldom updated English page on a Japanese site):
http://www.caravan.net/ec2plus/
The EC++ Language Spec:
http://www.caravan.net/ec2plus/language.html
Bridging C++, EC++ and C using iterators as an example (with an
excellent bibliography):
http://www.uaca.ac.cr/acta/2000may/c-iter.htm
(GNU, g++ and EC++ NOTE: The one-time gcc option "-embedded-cxx" seems
not to have made it into egcs. Since it only affected warnings issued
for non-EC++ language elements, and not the code generated, the
g++ compiler still groks EC++.)
Ken Raeburn (Cygnus gcc/g++ guru) in an EC++ thread:
http://gcc.gnu.org/ml/gcc/1998-12/msg00968.html
A point against EC++:
http://gcc.gnu.org/ml/gcc/2000-03/msg00598.html
(There are several commercial companies supporting EC++ with compilers
and tools. I've selected Dinkumware and Green Hills as informative
examples only.)
The Dinkum EC++ Library:
http://www.dinkumware.com/libecpp.html
The Dinkum EC++ "Proofer" (conformance checker):
http://www.dinkumware.com/ecproofer.html
Green Hills EC++ Home Page"
http://www.ghs.com/ec++.html
The Green Hills EC++ Compiler:
http://www.ghs.com/products/optimizingC++EC++Compilers.html
A bunch of other EC++ tools:
http://www.ednmag.com/ednmag/extras/embeddedtools/admin/embeddeddebuggersapprove.asp
Like any language, EC++ has its weaknesses, and it has not kept up with
the recent low-cost or "free" additions to the C++ spec (such as
namespaces and other things that affect only the compiler and not the
generated code). Some vendors have implemented extensions to EC++ to
cope with this. Other embedded C++ compiler vendors have started to
omit the term "EC++" from their product descriptions because the
compilers themselves are steadily improving, and some feel EC++ is an
artificial distinction. However, "bare" EC++ is still an excellent
place to start, especially if your goal is going head to head against
C. I'm certain it will make sense to use specific features of g++ that
are not part of EC++, but only when their low-cost and suitability has
been thoroughly verified.
And that verification task will fall squarely upon the shoulders of the
C++ zealots: They must bear the burden of proof, and will likely need
to write two versions of their code (EC++ and C) until that burden is
met.
The only near-term question is this: Should this contest be given a
venue within Plex86? That is to say, should Plex86 be made "g++
compatible"?
Politics aside, I feel there are good, sound technical reasons to do
so. It may even serve to attract additional programmers to the team,
those (such as myself) who are anxious for (E)C++ to succeed in the
embedded, real-time and system-level environments.
Though I've been using C for 20 years, I greatly prefer to use
C++ anywhere it will fit. Even though I have never shipped an embedded
or real-time system built with C++ (despite trying several times: my
systems all go into ROM), I still do my system prototyping (R&D) in C++
(or Python or Ruby), even when the final implementation will be in C. I
find OO languages encourage me to code at a much higher level, and not
sweat the "small stuff" until it is time to do so. That is, I find C++
(and other OO languages) encourage "top-down" development, while C
encourages "bottom up" development. OO languages also tend to map
closer to high-level tools (such as UML), allowing more work to be done
within the high-level tool (where time spent is vastly more productive).
-BobC
(Next week's topic: "Plex86 in Java?")
