Re: What if?

[James Bruce]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/