4 ms·

Indeed, the difference here isn't the capabilities of the language, but rather the quality of support the tool chain offers for the task. None of the tool chain

Indeed, the difference here isn't the capabilities of the language, but rather the quality of support the tool chain offers for the task. None of the tool chains that I know of offer decent support for building operating systems, but the C portion of the gnu tool chain offers the least sucky support for it. A sign of the flaws in the author's argument is that C++ clearly offers just as much control over the hardware as C. However, an order of magnitude more OSes are written in C than C++. Anyone who's tried to write one in C++ knows why; trying to bend the tool chain to support bare-hardware is a daunting task.

rjh 19y ago
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.

rjh 19y ago

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.