RE: What if?

["David Schwartz" <davids@webmaster.com>]

> While that may be true, the problem is that you don't know off the top
> of your head whether something like:
>
> 	a = b + c + d + e;
>
> involves primitive types or not just by inspection.  So it could be
> something that takes no time at all, or a monstrosity which takes a
> dozen or more memory allocations, and where it requires a Ph.D. in
> understanding obfuscated code to figure out which overloaded operators
> and which type coercions had actually taken place.  And remember, this
> is a language where you can even override the comma (',') operator.
> You think you know what a piece of code will do just by looking at it?
> Think again!

	You can write bad code in any language.

> That's the problem with C++; it is far too easy to misuse.  And with a
> project as big as the Linux Kernel, and with as many contributors as
> the Linux Kernel, at the end of the day, it's all about damage
> control.  If we depend on peer review to understand whether or not a
> patch is busted, it is rather important that something as simple as
>
> 	a = b + c;
>
> does what we think it does, and not something else because someone has
> overloaded the '+' operator.  Or God help us, as I have mentioned
> earlier, the comma operator.

	The UNIX way is to allow people to shoot themselves in the foot.
Overloading the comma operator is shooting yourself in the foot. If being
allowed to overload it is bad, then being allowed to do anything harmful is
bad.

> > In short, with C++ you can generate code as efficient as C or asm.
> > You just have to know how.
>
> You can juggle running chain saws if you know how, too.  But I think I
> would rather leave that to the Flying Karamazov Brothers.

	I know all the reasons why writing a kernel in C++ is bad, and I largely
agree with them. However, this argument I don't find convincing.

	The part of it that's correct is just this: with C++, it can be harder to
tell exactly what a line of code does under the hood. For user-space code,
the vast majority of the time, that's great, it saves you from having to do
a whole lot of work. However, for kernel code, the vast majority of the
time, you must understand exactly what's going on under the hood.

	DS