Messages in this thread | | | Date | Mon, 11 Jan 1999 17:08:05 -0500 | From | Chip Salzenberg <> | Subject | Re: C++ in kernel (was Re: exception in a device driver) |
| |
According to kwrohrer@ce.mediaone.net: > What OO features can be better optimized when expressed in the C++- > specific way? Virtual functions, for example, go just as fast when > implemented by function pointer [...]
Of course -- seeing as how that's the usual implementation technique. :-) Saying that C++ is intrinsically more efficient than C is just as ludicrous as saying that C is intrinsically more efficient than assembler.
However, available human effort is finite. So it's possible for a given C++ project to end up more efficient than an equivalent C project -- not because C++ is faster (it isn't), but because it's more convenient. And when grunt work is more automatic, that leaves more time for optimizing things that are actually performance-critical.
A simple example: Working with C++'s 'string' class is a lot more convenient and easier to verify as correct than the equivalent C string manipulation. Human time saved on verifying buffer lengths etc. can be used for other issues; this is a net gain in programmer productivity. And yet since C++ is a superset of C, if there's any particular thing you want to have 100% control over, C++ won't get in your way.
(This specific example isn't relevant to kernel internals because dynamically allocated strings aren't a staple of kernel programming. But the principle is still applicable.)
> [Some C++ compilers used to] generate absolutely horrible code when > asked to inline a virtual function...
With C++ compilers as with all other new programs, things get better over time. C++ compiler technology has made great strides in the last year. And while it's still true that EGCS, for example, is unable to inline functions with quite the same efficiency as the equivalent macros, this is a known issue that will be addressed reasonably soon.
> > Since the C language doesn't enforce these constructs then haven't > > we increased the complexity of the kernel for an unknown benefit? > > C++ doesn't enforce them either.
Um, it enforces whatever the programmer told it to. ("private" and "protected" aren't just synonyms for "public". :-)) Or did I not get the point?
> If it ain't broke, don't fix it. The design would be just as > complex if it were re-expressed in C++ from scratch, just terser. > [...] I think most of the complexity that belongs in the kernel is > already there.
Well-said. -- Chip Salzenberg - a.k.a. - <chip@perlsupport.com> "When do you work?" "Whenever I'm not busy."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |