You mean "hand coded", not "hard coded", right?
Also, 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, and in fact C++ compilers at least used
to generate absolutely horrible code when asked to inline a virtual
function...
> 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.
"Object Oriented Design" is largely a trick which is better at coaxing people
into making good code than "Structured Programming" was. The Linux kernel's
virtual filesystem layer, for instance, is essentially an abstract class
with concrete child classes for the various actual filesystems. And I'm
sure a lot of kernel programmers "implement" private and protected data
by leaving comments to the effect of "this is internal, don't mess with it".
> 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.
> 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.
Design abstraction comes from proper implementation of a clean design,
regardless of how many or how few goads were required to get either or
both to happen.
> 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?
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'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.
C++'s benefits to large projects are largely a matter of coaxing the
mediocre designer into thinking more clearly; mediocrity in the linux
kernel tends to get rejected or rewritten. C++'s benefits to high-
performance projects...uhh, what benefits? Short of exception handling,
I can't think of any.
Further, exception handling is the wrong thing to do in the kernel because
the stacks are so small and so much is done with dynamic or global data that
stack unwinding does very little...plus you could get an exception just about
any time, so you wind up with more try blocks than you ever had
if (rc==whoops) error catching. Add to this fact that most of the truly
exception-worthy errors (oopses and such) are detected by hardware, not
code, and are either already handled or not truly handleable.
> 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.
C++ is not a magic bullet, and I think that developers good enough to
understand the way the kernel works and the reasons it works that way
will submit well-designed code even without the "constraints" of C++...
and I also believe that if the kernel were rewritten in C++ they would
find themselves turning off those constraints on a routine basis.
> 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!
The answer is that people will have to understand what they're doing, pure
and simple. Depending on the features that get added, it may be that a
new abstraction or two will be added, or perhaps rules (not likely simple
enough to enforce at compile-time) on how to do certain things. Most
of the new features will either not add complexity (e.g. Ultra-66 EIDE
support, or a new serial port driver), will be rejected because they
belong in userspace or are needlessly complex as proposed, or add a
manageable amount of complexity (perhaps after some redesign of the rest
of the system). I think most of the complexity that belongs in the kernel
is already there; after the fine-grained SMP support introduced in 2.1,
I don't foresee anything nearly that difficult until we try to port it
to a quantum computer.
If the people who know what they're doing don't have time to add something,
I don't want people who don't know what they're doing adding it and
screwing everything else up. If there are so many important new things
that the "elder gurus" spend all their time thinking and training others
and only the disciples spend much time coding, so be it. But so far
the limitations on expert coders' time has served at least as much to
keep cruft out and keep features out before people have time to think
them through, as it has to hold anything back.
Keith (Windows QC...fear it)
-- "Well, look at that. The sun's | Linux: http://www.linuxhq.com |"Zooty, coming up." -- John Sheridan, | KDE: http://www.kde.org | zoot "Sleeping in Light", Babylon 5 | Keith: kwrohrer@enteract.com | zoot!" www.midwinter.com/lurk/lurker.html | http://www.enteract.com/~kwrohrer | --Rebo- 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/