>
>Benjamin's posting had the following contradiction which I think really
>points out why I am very suspicious about C++ as a language:
>
>>...This kernel is getting feature rich real quick and organizing its
growth
>>is getting more and more difficult (someone ask Linus!). We better start
>>letting the compiler start doing some of the menial tasks for us so the
>>geniuses (and I use this word literally) who have gotten us this far can
>>concentrate on keeping this thing from getting the size of NT-2000 and
>>making adding new features nearly an impossible task.
>
>... but yet earlier, he stated:
>
>> C++ (as opposed to any other OO-languages I know that have also been
>>suggested) can use extensive inheritance, method and operator
>>overloading, and other very expressive language-supported features with
>>Zero additional overhead as compared to its C predecessor. To do this
>>successfully requires that you have a good idea as to what's going on in
>>the compiler. This knowledge of how the language is implemented is also
>>a requirement of coding the kernel in C as opposed to assembly language
>>- we just take this knowledge for granted these days. Five to ten years
>>ago you couldn't do this and similar arguments against C by the assembly
>>language people were made.
>
>This is precisely why I don't like C++. It take an awful lot of work to
>reverse engineer what a C++ compiler is doing when there's overloading,
>virtual classes, type coercion, function overloading, and all the rest.
>
Do you mean the ASM or tracing what it is actually doing? I haven't had any
problem tracing what it doing. As for the ASM there may or may not be
substancial differences but that level (if any) is only due to the level of
complexity used in the code. A simple class' ASM probably would be much
different than a similar structure and its associated functions. And this
complexity need not be, it usually results purely from some programmer's
trying to be creative with their code. I've seen worse using creative
"#define"'s.
>On the one hand, C++ advocates keep saying that "the compiler will
>make things easy, because then we won't have to think about it". Yet
>when folks argue about performance, the argument is "you just have to
>know what the compiler is doing". This often means not just being an
>expert C++ programmer who can second guess the compiler, but searching
>through hundreds of C++ header files to see exactly how the classes
>were implemented!
>
The main thing the compiler would keep easy would be type safety and access
priviages (class-wise not system-wise) and these features shouldn't make any
difference in performance. And again the same cloudiness could be done with
#defines. There is not real agument about performance because any bloat
generated could have easily have been done in C and is not necesary to be
present. Obviously if someone start using unneeded, inefficient language
features bloat could appear in his code. But this does not mean that the
kernel will become bloated, actually most bloat arises from the C++
libraries and STL which are somewhat bloated because they were created
genericly to allow easy integration with programmers' tricks. And no future
C++ kernel would be using the standard library so no bloat would come from
that. And as far as searching C++ headers (and source) for how things are
implemented, are you trying to tell me you do not have to do this with C as
well? Just because its C doesn't mean you do not need to know how the data
is being initiated, used, or manipulated somewhere else.
>The question then is: how does the time savings spent by the
>"automatic" work done by the compiler (which we currently do manually)
>compare with the effort of figuring out why the following seemingly
>simpler line of C++ code:
>
> a = b + c + d + e(b,c)
The above syntax need never be implemented and I doubt very much that it
ever would be implemented as such in any future C++ kernel, except maybe for
a string class. And most C++ code would probably look something like:
objectname.functionname(arg1, arg2);
Not unclear, if anything it can be more clear than the C version of the same
code. However I would avoid the use of either exceptions or especially the
STL like the plauge as these features would lead to unfollowable/unreadable
code.
>
>which might result in several constructors, destructors, mysterious
>type castings, etc. works the way it does? And let's not even talk
>about function overloading when combined with type coercion. Trying
>to figure out which version of function e will be called can be its
>own adventure/mystery story. Thus, often C++ has *increased* the
>amount of work and complexity I've had to deal with, NOT decreased it.
>(Especially when I've had to maintain other people's C++ code.)
>
Which function being called would depend on the object and is not much
different than the same being done in C. Just look up the object and the
function under that object. Any small difference is a result of the OO
design and a small trade off. As long as the classes are kept relatively
simple everything remains easy to follow.
>Fundamentally, there are a lot of people out there who can't write
>good C++ code, and bad C++ code is infinitely worse than bad C code.
>I've always thought it telling that no one has ever bothered to hold
>an obfuscated C++ contest. Maybe it's simply too easy to write
>obfuscated C++ code?
>
This may very well be true. However I've seen the same being done in C with
creative "#define"'s, resulting in even worse readability.
>This is why IMHO handing C++ to the average programmer seems roughly
>comparable to handing a loaded .45 to a chimpanzee. Sure, a trained
>expert can handle the handgun safely --- just as a trained, expert OO
>programmer can write clean C++ code. However, I don't want to be
>anywhere in the vincity when a monkey starts playing with the .45,
>just as I don't want to be nearby when the average programmer starts
>playing with the C++ language. (And there are probably more people
>with safety training with small arms than there are competent C++
>programmers. :-)
>
Many, especially those guy trying to force Java upon us, say the same about
C.
> - Ted
>
>P.S. This is the exact same argument why I believe threads have no
>place in many application programs. It's not that threads are bad, but
>they're complicated, and if you can program threads well, you'd be a
>good kernel programmer. (And we've seen how hard it is for kernel
>programmers to get this right, given the various race conditions and
>dead locks we've found in the kernel over the years.) And we want to
>put all of this complexity and potential for lossage in the hands of
>*applications* programmers, who generally have far less experience in
>this sort of thing that we do?!? Pardon me if I seem unconvinced....
>
I agree with you here. The problems bought in by threads usually aren't
worth the trade off.
>Yes, yes I know --- call me a traditionalist. But I've had real-world
>experience having to work with or maintain other peoples' attempts at
>threads or C++ code ---- and the old saying that a conservative is a
>liberal who's been mugged is very much applicable here.
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.rutgers.edu
>Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/