Hi. I'm the original author. As far as I can see, the reason why C++ has never really taken off for OS design is both historical and technical. When I was wo

Hi. I'm the original author. As far as I can see, the reason why C++ has never really taken off for OS design is both historical and technical. When I was working at a major telecommunications firm, our C++ coding manual dated back to 1985--any features that weren't stable in C++ as of '85 simply could not be used in modern code in '99. Large scale engineering shops are very, very slow to change. Right there's one major reason why C++ hasn't caught on in the OS level. The other major reason has to do with the way C++ implements inheritance. The fragile base class problem is a killer for OS level design. If you want to dodge that, then your best bet is to write your kernel in the C subset of C++ and eschew C++'s object model. Finally, there's the issue of portability. C++ didn't even standardize until 1998. Compilers lagged substantially behind the Standard until about 2003. Using sophisticated C++ features like the STL tended to lock you into one particular compiler vendor. That's not something an OS designer especially wants. I know of several engineering shops that write their code in C, precisely to get around vendor quality-of-implementation issues in their C++ compilers. However, despite the fact they write their code in C, they make compiling it with a C++ compiler part of their software engineering practice, in order to take advantage of the C++'s compiler's much stronger type checking. I have yet to see the tool chain be an issue in C++ development. That's not to say it can't be an issue or that you haven't seen it--only to say I've never seen it become a substantial issue.