Re: C++ and the kernel

[Sau Dan Lee]

>>>>> "Chris" == Chris Friesen <[e-mail]> 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
functions.

    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
code.)

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                     §õ¦u´°(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: [e-mail]
Home page: http://www.informatik.uni-freiburg.de/~danlee