DragonFly BSD
DragonFly kernel List (threaded) for 2003-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: C++

From: David Leimbach <leimy2k@xxxxxxx>
Date: Sat, 19 Jul 2003 10:27:53 -0500

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 could
probably go on for days listing them. I do not personally like C++
very much, but the biggest reason not to use it is that we are working
with over 300 megabytes of C code and that means we're doing it in C.

OK, I'll clarify.

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 win.

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:

For example.

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 datatype.

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

int a,b,c;
. ..
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 work.

[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.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]