lkml.org 
[lkml]   [1999]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.095 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site