[lkml]   [2002]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: C++ and the kernel
>>>>> "Chris" == Chris Friesen <> writes:

>> It is quite unlikely that a C++ compiler will make more
>> efficient code than a C compiler. In fact, the code generator
>> will likely be the same. The C++ compiler will end up
>> generating some preamble code as part of the function-calling
>> mechanism, that is not necessary in C. This means that it will
>> generate a bit more code.

Chris> C++ has tigher constraints on code than C. This can allow
Chris> a compiler to generate better code because it has more
Chris> knowledge about what is going on.

There are also many GNU extensions to C that makes it possible to
generate better code, e.g. marking certain functions as pure

Chris> Your example is needlessly complex, and I'm sure you know
Chris> this. A more realistic comparison would be:

Chris> cout << "Hello World!\n";

This has demonstrated that you don't know C++ _very_ well. Instead of
the trailing "\n", a C++ programemr ought to write:

cout << "Hello World!" << endl;

You seem to *understand* C++ even worse than Richard. Even Richard
used "endl" in his unnecessarily complex example. And you're not a
better programmer, either, because you failed to distill out the EOL
concept and represent it in an abstract, OS/platform-independent way.

Chris> Now I don't for a moment think that we should go and
Chris> convert everything to = C++.=20 But I do think that certain
Chris> features of the language can be useful, and tha= t there
Chris> are cases when OO style programming makes the code easier
Chris> to read and understand.

I don't find the current Linux fs code is too difficult to understand,
although it is doing OO in a non-OO language. Rather, I think this is
easier to maintain, because you don't have to go through all the
burdens of writing the C++ code. (It's easy to get a working C++ code
work. But making it efficient (e.g. sprinking "const" to wherever
possible so that it becomes a potential for the compiler to do
optimization) and *flawless* (e.g. multithread-safe, reentrant,
SMP-safe, **side-effect-less**, privatizing all dangerous copy
constructors as well as assignment operators, no memory leakage...)
would be very devoting. The time could better be spent on the C

Unless the FS code gets the complexity comparable to Xt (tall
inheritance trees), I don't think the overhead of doing it in C++
worths. (Xt is still bearable when used as a user. But if you try to
extend it (by writing a few custom widget classes) or maintain code in
it, you'd wish it were in C++.) How deep would the FS code grow to?
If it is shallow, then IMO, don't do it in C++; you'll be spending
more time for the cosmetics than really getting advantage out of it.

Sau Dan LEE 李守敦(Big5) ~{@nJX6X~}(HZ)

Home page:

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.048 / U:1.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site