Willy Tarreau wrote:
Sorry , but all the examples that have been given in C++ are clearly
unreadable and impossible to understand.
If you don't know C++, sure.
Maybe this piece of code
f [] = []
f (x:xs) = f [y | y <- xs, y < x] ++ [x] ++ f [y | y <- xs, y > x]
Isn't very readable to a C or C++ coder, but it's meaning is instantly
clear to one who knows the language it's written in. The equivalent C or
C++ code is ~30 lines long and you might need a pen and paper to work
out what it does.
I'd also like to note that
people were arguing about what the code was really doing, this means
that this language is absolutely not suited to such usages where you
want to know the exact behaviour.
Were they C coders or C++ coders?
At least in C, this sort of thing
has never happened.
Like the recent prevent_tail_call() thing? Granted, C++ is a lot tricker
than C. Much self-restraint is needed, and even then you can wind up
where you didn't want to go.
People argue about what must be locked and important
things like this you'd never want the compiler to decide for you.
No one suggests that C++ can decide what needs to be locked or not. To
be sure, if there was a language where you could specify the locking
rules in a central place (the class/struct declaration, for example) and
let the compiler apply them, races and deadlocks would be much scarcer,
and people could argue about what needs to be locked when the data
structure is written, not every time it is used.
To be secure, you first have to understand what the code precisely does,
not what it should do depending on how the compiler might optimise it.
If optimization changes your code's behaivor, your code is broken.
People rely on the C++ optimizer for much the same things as C: to
inline zero- or one- line functions and remove unused code. (There is
just one exception in C++ where the optimizer _is_ allowed to modify
behavior, but it is for an obviously correct scenario).
I'm still thinking that people who have problems understanding what the
code does want a level of abstraction between them and the CPU so that
the compiler thinks for them.
No, they want not to repeat code and code patterns. It's the same
motivation that lead to the invention of functions:
- functions allow you to reuse code instead of open-coding common sequences
- constructors/destructors allow you to reuse the do/undo (lock/unlock,
etc.) pattern without writing it in full every time
- templates allow you to reuse code even when the data types change
(like the preprocessor but not limited to linked lists)
- virtual functions allow you to dispatch a function based on the
object's type, without writing the boilerplate casting
- exceptions allow you to do the detect error/undo partial
modifications/propagate error thing without blowing up the code by a
factor of five
It's just shorthand: but shorthand allows you to see what the code is
doing instead of how it handles all the standard problems that occur
again and again in programming.
The C people are content to stop at functions, but resist _all_ of the
rest (it's okay to do some template-like magic with typeof, because it's
still C, right?).
I still don't see the *current* problem
you are trying to fix. Linux is written in C, as many other kernels and
it works. Nobody knows what it would become if rewritten in C++. Maybe
it will be better, maybe it would not run anymore on embedded systems,
maybe it would become fully buggy because nobody except a little bunch
of C++ coders would understand it... At least, I'm sure it will not be
the smart people who currently work on it.
Maybe it would be smaller, faster, more robust, and have even more
flexible and fast-paced development.
Perhaps people who developed kernel-level code in _both_ C and C++ would
be qualified to speculate on that (I have, but apparently I don't have a
clue).
Best of all, I'm even sure that people who are trying to push C++ in
the kernel would never ever write a line of code once it would be
accepted, because they don't seem to know what they're talking about
when it applies to kernel code.
Thanks.
--
error compiling committee.c: too many arguments to function
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
