Re: C++ in kernel (was Re: exception in a device driver)

Tim N. van der Leeuw (fltn@yahoo.com)
Tue, 12 Jan 1999 06:34:14 -0800 (PST)


Ok Mark,

I don't know what your stance is on the C vs C++ debate so don't take
any of my comments personally. I'm ranting about C++ in general. And
yes, I do know C++ and thought it was really superior to C before I
actually started programming in C. I can now happily live without all
the features of C++ that I considered so wonderful at first.

I'm not anti-OOP. I love OOP. But C++ has bitten me hard and C doesn't
do surprise-tricks behind my back.

Ok, rant-off, let's comment on the previous mail.

Mark H. Wood (mwood@IUPUI.Edu) wrote:

> On Thu, 7 Jan 1999, Alan Cox wrote:
> [deletia]
> > Another big C++ problem with an OS kernel is that it tends to hide
things
> > like memory referencing. With C you can accurately see where you
have cache
> > issues, where there are going to be excessive reloads and also see
clearly
> > where objects are dereferenced which is very important for SMP.

> So instead of C++ we should be talking about converting to Bliss? :-)

I don't know Bliss. I don't know if it's a higher level or a lower
level language than C. I guess it's a lower level language. Doesn't
matter.
Alan's comments about knowing what will happen to your code can easily
be ridiculized by replying "so let's do the whole thing in assembler,
if you want to know what's going to happen to your code". However, the
point is not to know exactly what machine instructions will be
generated at each turn of the code. The point is to strike a balance
between low-level control and abstraction. C seems to give that
balance for systems programming at kernel-level. It's a wellknown
language and it's pitfalls are numerous but well-understood.

C++ adds lots of features which are complex and can introduce many
unforseen calls. To avoid the pitfalls, programmers have to learn a
whole new set of ugly things to watch for ON TOP OF the known traps of
C. Many of the goals of C++ can be achieved by using other, less
complex, languages. Oberon comes to mind.
If there's a fear that the complexity of the Linux kernel will become
too much to keep it maintainable with a complex language like C, then
replacing C with an even more complex language like C++ will only make
things worse. Potentially disastrous.
So instead, a re-write in a less complex (OOP?) language would be more
beneficial in the long run even tho it's extra work in the beginning.

Those are only my opinions of course. I'm not trying to push anyone in
the direction of rewriting the kernel in
[Oberon|Ada|Perl|Forth|ObjectPascal|ObjectC|<insert pet-language
here>]. I'm trying to make the point that if a re-write is felt
nessecary, C++ would be a bad choice.

> --
> Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
> Innovation is only valuable if it improves one's life; otherwise it's
> just one more silly change to cope with.

And it seems to me, that for the Linux kernel C++ is just that silly
change to cope with rather than being an improvement to the life of
the kernel programmer.

Kernel programming is complex enough in itself and learning the fine
points of C++ programming and compiler implementation details just
adds lots, lots more complexity to be managed.

Once again Mark, don't take my comments as a personal attack on what
you wrote. Your mail just triggered a while train of thoughts in me
relating to everything said in this thread.

That said,

Happy Hacking everyone :-)

--Tim (tnl@tifa.demon.nl)

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
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/