C++

[David Leimbach]

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++)
	do_something(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
example].

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.

Peter