AFAIK you cant use system() calls in C++, not that its all that important.
AFAIK you cant use system() calls in C++, not that its all that important.
I'll throw my 2p in the collection:
There is nothing you can do in C, that can't be done in C++, that is useful in an operating system (or any other low-level code). The company I work for has the entire OS written in C++ (and yes, it's C++, not just C compiled with a C++ compiler).
The OS I work on is a mid-to-high-level Embedded OS, so it has low-level funcitonality in the OS for sure.
There are things in C++ that can't be done in C that may be useful (such as using destroctors as unlock for locking primitives - so you don't have to remember to end your function with "unlock(lock)" at all exit points).
The main reason that OS's traditionally hasn't been written in C++ is the lack of support for C++ compilers ten-fifteen years ago, and lack of skilled C++ programmers that are also skilled OS developers.
You can not write a complete OS without some assembler, however. There are a few things you can't do in (standard-ish) C or C++:
- Context switch (save registers, switch stack, restore registers)
- Interrupt setup (usually, you have to write to some special register(s))
- MMU setup (again, special processor registers need to be accessed)
- Lock primitives may need special assembler instructions.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I would have thought that exceptions were one of the main features that would make C++ such a great language for writing an OS in - much easier to follow.
A great feature indeed. I'm serious. Sometimes it's not worth the expense though. I've seen a single throw/catch add over 2.5K to the code size on a PowerPC. I believe it was an up-front price that you could leverage as you added more (similar to a full-featured printf cost), but it really depends on how much code space you can afford to spend for that. It's another hidden mechanism that I don't have to account for when I write a program in C.
Additionally, I can't throw from system space to user space if my OS supports address spaces, or from interrupt to mainline code, so I end up having to return an error code anyway. Of course the answer is that C++ supports all of that stuff too, but exceptions are always on in standard-ish C++. If I can't afford the exception mechanism, and I can't use implementation extensions to disable them, then I'm forced back to C.
Last edited by whoie; 08-30-2008 at 12:30 AM.
I agree, Elysia: it's a trade-off. A fair few compilers allow exception handling support to be turned off though, and some recent ones only give significant runtime overhead if an exception is actually thrown.
I seem to recall seeing a mention of one compiler that would turn off exception support for functions declared with extern "C" too, but never confirmed that was true.
No, Win32's MS ABI is actually the only (I think) remaining fairly modern system that does have overhead when no exception is thrown, since it bases the exception off SEH.This fits the bill of VC exactly. Exception overhead is huge, but only if thrown.
I think this changed in Win64.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.