Timur Tabi <[EMAIL PROTECTED]> said:
> Horst von Brand <[EMAIL PROTECTED]> on Wed, 27 Sep 2000 16:50:12 -0400
> > I'd say it is important specifically in device drivers, and less so
> > elsewhere ;-)
> Yes, it's more important, but I've looked at the assembly code that my
> C++ compiler generates, and it's very clean. In fact, when you're
> writing code that by design is OO, then using C++ tends to generate
> better code, not worse, since the language more closely matches the
> design.
Your compiler being? I for one wouldn't trust others, C++ is still very
much in flux in gcc...
> > A couple of points:
> >
> > - The kernel is C, mixing in C++ for no *real* good reason is just making
> > it harder to work on.
> True, but I'm not advocating doing it for no real reason. I'm advocating
> using C++ for code that is OO by design. My OS/2 device drivers are a
> mix of C and C++, wherever appropriate.
The kernel is OO in design, just not written in C++. And as I said before,
you either redesign Linux from the ground up for C++'s idea of OO, or use
wrappers and pay the cost in bloat and performance. Neither is acceptable...
maybe for a specific case, but not for general use.
> > - The work you do to match the kernel's object model to C++ is strictly
> > wasted effort: The kernel's interfaces _do_ change, sometimes radically,
> > and you'll have to keep up
> But that applies to C code as well. In fact, the #2 gripe I hear about
> Linux development is how the API's change so often and without any regard
> to existing code that depends on it. (#1 gripe: the dearth of good
> development tools).
Gripe #1 is complete nonsense (not _that_ thread again...), gripe #2 is
mostly nonsense (sure, Linux could still have the internal interfaces from
1.0, but the cost would be prohibitive for an OS that wants high
performance on machines that are at least an order of magnitude larger than
they were then).
And for whatever #2 is worth, you are only making it _harder_ for yourself
to track the changes by plastering something over the interface.
> > - The idea of reusing code from other OSes with a very different internal
> > layout will only make the point above even worse
> Not always true. Some drivers, like complex PCI audio drivers, are mostly
> OS-independent. They get some data from the OS, and then spend 90% of their
> code just talking to the hardware.
> > - History shows that no kludged-on C++ code will show up in the standard
> > kernel, so you loose the main advantage Linux gives you: Hundereds of
> > other people that fix bugs and port forward for you
> True, if you want to write a driver that goes into the kernel, you need to
> conform to Linus' whims^H^H^H^H^Hstandards. But considering how difficult it
> is to get a driver into the kernel anyway, it often doesn't make a
> difference.
I'd be a bit more careful. It is in large part those "completely
ridiculous, nobody will ever be able to write decent software that way"
whims that got Linux to where it stands today.
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
