lkml.org 
[lkml]   [2004]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: What if?
Theodore Ts'o wrote:

>The way the kernel will deal with C++ language being a complete
>disaster (where something as simple as "a = b + c + d +e" could
>involve a dozen or more memory allocations, implicit type conversions,
>and overloaded operators) is to not use it. Think about the words of
>wisdom from the movie Wargames: "The only way to win is not to play
>the game".
>

I think this oft-repeated argument is a strawman, since C++ and C are
identical on primitive types, and for non-primitive types, C can't use
operators anyway. So translating some C++ thing like your example where
[a,...,e] are all "struct foo", we would have a C function called
"bar(a,b,c,d,e)". Well, guess what, without looking at its definition,
it could be doing all sorts of things too. In C++ you look at the
struct definition and the C++ standard, in C you look at the function.
How is that so different? In C, functions are arbitrary but operators
are not. In C++, both are arbitrary. Considering that Linux wraps
almost everything into function calls, there would be little difference
in the end.

That's not to say I think C++ is a good idea for the kernel; It isn't.
C++ is more complex in the sense it requires more analysis to figure out
what the CPU is really doing, thus it does entail a higher cost. It's
not that bad for an expert, and in a large part it depends on how many
of the advanced features you use; Don't use them and your code is
practically the same as in C. So it really boils down to what you
*gain* compared to that extra analysis cost. For a kernel, there is
really not much gain. "Some cost vs. little gain" implies "not worthwhile".

For example, filesystems would probably be more cleanly implemented as
classes with virtual functions, but as the kernel code shows, with a
little extra effort you can achieve the same thing with structs of
function pointers in plain C. Extra effort is easy to come by when you
have thousands of contributors, so there's no real difference. The case
is similar with many other C++ features.

The C language was developed for writing the original Unix kernel and
utilities, and not suprisingly it has all the features you need for
that. C++ was developed for improved development of user applications,
mostly through more effective reuse of code. So again, not suprisingly,
applications are what it is best at. Let's also try not to mix up "use
the right tool for the right job" with "use the best tool for my normal
job for all problems". Many people who espouse one language above all
others need to look outside of their own usual problem area.

- Jim Bruce

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.346 / U:0.108 seconds]
©2003-2014 Jasper Spaans. hosted at Digital Ocean