> (not that I'm defending C++ support in the kernel, but...)
>
> "We'd need all of C++, or nothing" is a bogus argument. It's perfectly
> reasonable to want to use a subset of C++, since C++ is such an
> all-inclusive language.
No. I'm agains using subsets of languages. Use it all, or don't use it.
The last thing we want here is a 'Well, I used an exception handler, and
it ate my primary disk. How come ??' -> 'Well, the docs say you can't use
exception handlers in kernel space'.
Just to give an example.
> At my last systems programming job (at
> Geoworks) we had a whole graphical embedded OS implemented in C++ and had
> basically no bloat or performance problems (and it had one of the only
> Java implementations I've seen that didn't suck performance-wise :-).
> The problems we ran into were almost always related to crappy C++
> support in embedded compilers; it was always nice when we got to use g++.
I'm not against C++.. It can make code readable and maintainable.
> Of course, 2/3 of our coding conventions were made up of "don't use X
> feature of C++", where some values of X were "templates" and "exceptions".
That means you trowing a big part of things that make C++ so usefull. With
such restrictions I would probably use straight C.
> Even (especially) with that stuff removed, you get a reasonably
> straightforward language for systems programming. Of course, we also
> shipped OS + apps as a single, statically linked image (appropriate for
> a cell phone w/ no MMU), so we also didn't have to deal with the binary
> compatibility problems that C++ frequently brings.
'I'll call you back in a moment mum. My phone needs a kernel recompile'
:-))
> miket
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:21 EST