DragonFly kernel List (threaded) for 2003-07
On Friday, July 18, 2003, at 9:29PM, Peter Dufault wrote:
On Friday, Jul 18, 2003, at 22:08 US/Eastern, Matthew Dillon wrote:
There are lots of reasons to not use C++ in the kernel, one couldOK, I'll clarify.
probably go on for days listing them. I do not personally like
very much, but the biggest reason not to use it is that we are
with over 300 megabytes of C code and that means we're doing it
I'm not a C++ programmer. I even program for PIC microcontrollers
where I can't easily use structures because the target debugger blows
up, but the code is still C++ because I can overload the assignments
on Unix for simulation. So I'm not a C++ zealot.
arrays with enum "fields" eh? :)
But simple inheritance and automatic construction/destruction is a big
I disagree. You can get inheritance in C... I actually have [up until
this post maybe :)] KDE commit
access. What I have found is that people generally don't understand
where implicit object "constrcution"
and destruction occur. This generally wreaks havoc on performance:
Iterator it = something.begin();
for (; it < something.end(), it++)
Guess what happens in the above? Can compilers easily optimize "it++"
to be +"+it"? Probably not since
its an overloaded operator on an object and Iterator is not a plain old
As a result, at the end of every iteration of the for loop you
construct a copy of the original value
of "it" and save it while incrementing the real value of "it"
internally... then return the copy. [postfix
increment semantics]. An iterator is both constructed and destroyed
which you probably never even wanted
at the end of each loop iteration.
I don't think operator overloading is really that good an idea in
C++... think of what happens in the
following expression for the "int" datatype vs the "Integer" class you
may have written [just as an
a = b + c;
Integer d, e, f;
d = e + f; //implicit temporary between the result of e and f being
assigned to d?
//can the compiler optimize this away?
Basically you have a similar situation where the compiler doesn't know
that the way you overloaded the
operators even does what addition does. Its a known fact that
compilers have an awful time optimizing that
to have no unnecessary copies.
That's why things like PETE [Portable Expression Template Engine]
exist... Now the solution to having "nice
syntax" involves a hack on the template engine that just happens to
[http://www.acl.lanl.gov/pete/] for more information.
Doesn't sound like operator overloading bought us much... but it sure
costs a lot.
I have other examples of why I don't like C++ so much anymore for big
projects [mostly due to the very
limited number of good C++ programmers in the world].
You could go on for days listing reasons for not using C++ in the
kernel, but (and I'm NOT a C++ zealot and much of my final code is
always pure C) you could go on for days as to why now-a-days you
wouldn't start a major project in pure C.
I certainly can't say why I wouldn't start a project in pure C after
the times I've had with other languages.
I don't know of too many good alternatives for writing kernels. Many
L4 implementations are done in C++ now..
at least a limited subset. I am just not sure the complexity of the
language is worth the benefits.
Anyway, this heated up much faster than I'd hoped. If you were
assigned to develop a kernel using a selected subset of C++ that had
to hook in with a large C code base would you have responded with that
"the mass of the existing code base means we're doing it in C"?
Written many C wrappers around C++? Its certainly doable... I've done
it. You have to learn to like
extern "C" linkage and passing C++ objects through void *'s [or empty
structs for extra type safety in C]
. ... but it does work.
This was an architectural question from a bad but better than most C++
programmer who is primarily a kernel and embedded system programmer
who primarily works in pure old-fashioned C.