Alan Cox wrote:
> > to prevent the self pointer from being passed, make it a non-member function
> > or make it a static member function, and stop complaining...or depending
> > on what foofunc is notionally supposed to do, leave it non-static so the
> > A writers of child classes don't have to fix it for you.
>
> So to write optimal C++ I have to know at least as much as the internal
> structure of the code than for C.
Naturally, the closer you get to the metal the more you need to know what the
compiler you're using is doing. This is the case for *any* language. However, C++
has some language features that let you specify optimal code constructs that would
otherwise have to be hard-coded in C. The fact is that you don't need to know any
more than you would with C and some times less.
> Thats the point I was trying to get across
> C++ is less efficient because the compiler cannot perform some optimisations it
> can in C without help from the code writer.
This is 100% false. C++ is a superset of C. Any valid ANSI C code (with a very few
well-specified specified exceptions) is by definition valid C++ code. Any "help" a
coder can provide in C can be provided in C++. Indeed, C++ has the asm keyword
which lets you get just about as efficient as it can get.
> Its exactly those kind of things that make C++ uninteresting for serious
> performance sensitive and large projects. Poor language design - not poor
> concepts - Linux is object oriented - but in C for example.
I don't know how you can possibly make this claim given the previous related
experiences and examples of C++ being used in just the kind of projects you
describe. C++ was designed specifically for large projects that C couldn't handle
well and without paying any language-imposed performance penalties. Since the
language has some advanced constructs built in that must be hard coded in a
C-equivalent program, the compiler has the opportunity to provide some performance
benefits without the hassle of the code-base overhead.
Now... I've seen a couple of people claim that Linux is object oriented. I would
really like to know how the people using this term define "Object Oriented" and
some examples of how Linux qualifies as such. Since the C language doesn't enforce
these constructs then haven't we increased the complexity of the kernel for an
unknown benefit? If this benefit wasn't unknown then please fill me in on what it
was believed to be and whether or not you believe its been achieved. Finally, if it
has, please tell me why we wouldn't want to re-implement these design constructs in
a language that supports and enforces them to further reduce the complexity of the
kernel design?
I'm tired of the attacks on C++ that come from people who obviously don't have an
understanding of the design of the language or how it applies to large
high-performance projects. As far as I'm concerned its not an issue of ASM vs. C
vs. C++ vs. Java vs. Logo! In a previous message in this thread I bring up several
issues regarding the future of the Linux kernel. I proposed C++ support as a
potential solution to these issues. No one has bothered to address these issues at
all, much less confirm or deny that they shared these concerns. Rather, all I've
seen are attacks on C++ that are simply baseless. Certainly there are some features
in C++ that aren't appropriate for the Linux kernel - the solution is DON'T USE
THEM! You don't pay for what you don't use. On the other hand, there are many
benefits of the C++ language. We may ignore the concerns that these benefits
address but, rest assured, they will not ignore us.
Linux is going to grow beyond what the current select group of very talented yet
temporally limited (i.e. not enough time) developers will be able to manage. Adding
features will become a tremendous effort just in terms of predicting its impact on
the rest of the system much less attempting to implement them. This isn't going to
happen overnight but just think back at how much the system has changed since 1994
(when I first started using it). If the solution to push back this inevitability is
not to move to a language that was designed to address these issues then please
tell me what it is!
thanx & later,
Ben Scherrey
-
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/