I hate to tell you, but when Ramon & Kevin agree on something you might as
well just go jump off of a cliff then try to convince them otherwise; I've
been here for a long time--believe me. Therefore C it is--whatever problems
or gains that may entail; it isn't worth arguing about anymore.
Drew Northup, N1XIM
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Robert W. Cunningham
> Sent: Thursday, January 04, 2001 12:23 AM
> To: [EMAIL PROTECTED]
> Subject: [plex86] More on C++ [long] [Was: Happy PERFORMANCE]
>
>
> 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/embeddedde
> buggersapprove.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?")
>
>
>
