From: yseeley@leland.Stanford.EDU (Yonik Christopher Seeley) Subject: Re: C++ is yucky Date: Fri, 9 Jul 1993 08:43:03 GMT
In article <BWH.93Jul9024054@beach.cis.ufl.edu> bwh@beach.cis.ufl.edu (Brian W. Hook) writes:
>
>Hmmmm, Linux doesn't compile under cc? And C++ is not portable....which
>version of C++ are we talking? 2.0? 2.1? 3.0? ANSI draft? g++? cfront?
Well, it would be portable to anything that gcc was ported to. The version
of C++ that we are talking about using is all of the above. Any of the
features used would be common to all of the standards you mention. Please
list an important incompatibility that would make a difference. There
may be some I am not aware of. BTW, g++ & cfront are implementations,
not standards.
>
>> PERFORMANCE:
>
>> As noted earlier, much of the time gcc produces the same code for ANSI
>> C as it does for C++.
>
>I don't understand this....the performance difference between C and C++ is
>entirely up to the implementation. A bad implementation of C++ is MANY
>times slower than an implementation in C. A good implementation of C++ is
>marginally faster than a good one in C.
- Basic C code gets passed strait through.
- Overloading is done through name mangling and thus is equivalent to
strait C code.
- Basic classes are equivalent to structs and are handled the same way
C structs would be.
- When you get to virtual functions, almost everyone uses the same
basic implementation of virtual function tables.
More advanced features may be implemented differently, but I doubt
you would see them in the kernel any time soon. I doubt even virtual
functions will make it into the kernel for a while (if ever).
The lowest level that I can think of implementation differences between
cfront and g++ has to do with the returning of a local object from
a function.
In g++
-------
- copy constructor is called, and returned object is copied into a temp
- destructor is called for the local
- function returns and any references to return value will refer to temp
In Cfront
---------
- lifetime of the local is extended. copy constructor + destructor
are not called even though the object was a local automatic
- function returns and any references to ret val will refer to original
- destructor is finally called for the object at the end of the
block that the function was called in.
In this case Cfront wins, for it saves an extra constructor + destructor
call. Anyway, I digress....
>
>> MAINTAINABILITY:
>
>> Stricter type-checking, more warnings, and type-safe linkage make it
>> more likely that errors will be found at compile time rather than at
>> run time. Objects, overloaded functions, and inheritance make it
>> easier to change the implementation of a module without having to
>> worry about breaking the rest of the system.
>
>While this is true, using -Wall with gcc, or whatever switch for whichever
>compiler, will give you all the warnings you need. Remember, strict
>typechecking under C++ was implemented mostly to avoid name clashes with
>overloading functions.
>
>Objects, overloaded functions, and inheritance tend to obfuscate code in a
>big way.
Only if you use them wrong.
This is a useless example since ints and floats can be converted
automatically, but use your imagination. Which style is more
obfuscated?
double add_float_to_int(float f, int i)
double add_int_to_float(int i, float f)
double add_float_to_float(float f1, float f2)
double add(float f, int i)
double add(int i, float f)
double add(float f1, float f2)
// for those new to C++, the latter group represents one of the
// simplest advantages: overloading.
>There are very few out there who know enough C++ to be make the
>code extensible. C++ is NOT a very good language to write object oriented
>code, unless you try to use templates....code reuse really isn't an option
>with the current implementations of C++ unless templates are used, and they
>are kind of flaky. And g++ is not compatible with cfront from what I hear.
What do you see wrong with inheritance? Why isn't code reuse possible
without templates?
>
>> READABILITY:
>
>> C++ code is easier for C++ programers to read, but tougher for those
>> who don't know C++. For those who don't know C++, this might be a
>> good way to gently get introduced. It might be a very long time
>> (perhaps never) until the kernel uses the more advanced features. It
>> would be nice if they could be used where appropriate.
>
>So what is C++ code is easier for C++ programmers to read? What about
>beginning C++ programmers? Who can tell the difference when foo->bar() is
>called and bar is overloaded six classes deep, but not defined for the
>current class, or even worse, was forgotten to be made "virtual" so that
>the correct method would be called by some high level routine.
Yep, good OO design can be tough, I'll give you that much. Most of the
problems you talk about can be attributed to bad design.
>
>> UNIVERSALITY:
>
>> Oh well, I guess we won't be like everyone else. Truth is, you never are.
>> Not all programmers embraced K&R C or ANSI C, so we cannot expect that
>> everyone in the world will use the same programming language any more
>> than we can expect them to use the same natural language.
>
>Quite true. Not everyone even uses the same version of the same language.
>
>> Oh, if you didn't notice, I think C++ for Linux is a good idea.
>
>I personally think that C++ would be great for an OS if only a select few
>C++ wizards were using it. Unfortunately, a lot of people expect too much
>from C++ and it never does what it is supposed to do. There are too many
>hidden things and anomalies with the language for something that is
>supposed to be hacked upon by the masses.
I gotta agree with you there. I have seen awful things done in C++, but
I have seen things just as bad in C. I have been a TA for C and C++
classes, and some of the stuff I saw made me realize just why the
government went to a language like ADA. Trusting the masses with
C code can be truly scary also. You are just going to have
to trust Linus to keep the kernel clean.
- Yonik Seeley
yseeley@cs.stanford.edu
>
>Brian
>
>
>--
>//----------------------------------------------------------------------------
>// Brian W.K. Hook "Stop! Stop in the name of all that
>// ( bwh@beach.cis.ufl.edu ) which does not suck!" - Butthead
>//
>// In this order: Meg Ryan, Sherilyn Fenn, Kristy Swanson, Milla Jovovich,
>// Bridget Fonda
>//
>//----------------------------------------------------------------------------