:gb2gbs:
Printable View
:gb2gbs:
Quote:
Originally posted by JoeSixpack
>Global variables aren't like those in C and have to be initialized before hand by the runtime
Code has to be inserted to call constructors and destructors. The bog standard C runtime uses a similar technique to initialise stuff.
>The new and delete operators require memory mangement in part of the host OS.
Is this required by the C++ standard? Is it required by the C standard that malloc/free require memory management in part by the host OS?
>Error handling is also handled by the OS.<
Do you mean exception handling?
>Of course, you can turn all these features off if you're using a compiler like GNU gxx, but then, you're just really using a C++ compiler for C-like code.<
Rubbish.
>So, the main parts have to be written in C (or ASM) and then you can use C++.<
You can use C++ more or less where you use C. I suspect C is used more frequently for lower level suff due to historical reasons (ie as stated earlier C++ compilers are not always what they might be; and companies have built up large libraries/tool sets that assume the use of C).
>ASM is needed no matter what as the boot loader must be in real mode and 512 bytes long (if on a floppy), etc, etc....<
The bootloader is not the kernel.
1) The runtime has to run the contructors of global class instances.
2) The new/delete operators are just wrappers for malloc/free. Those are OS functions that need to be made in C (or limited C++). And yes, those operators are part of the C++ standard.
3) Error/Exception handling (mean the _almost_ same thing to non-Java/.NET programmers), is also handled by the OS using trap handling and that stuff.
4) Nope, gxx, the GNU C++ compiler, can turn off language features. This is the command line I use to compile the display.cpp file in my OS:
gxx -c display.cpp -ffreestanding -nostdlib -fno-builtin -fno-rtti -fno-exceptions
5) You are correct, you can use C++ anywhere as long as you turn off those features. In fact, you can compile your whole OS in C++ using the command line I used.
6) Geez, sorry..... :-D
Don't believe me? Use this as a reference:
http://invalidsoftware.net/os/
Speedy
>1) The runtime has to run the contructors of global class instances.
I'm not disputing it. I just couldn't see what the problem was. You're just having to insert the code that a C++ compiler would normally do anyway, if it wasn't being used in a freestanding mode.
>2) The new/delete operators are just wrappers for malloc/free. Those are OS functions that need to be made in C (or limited C++). And yes, those operators are part of the C++ standard.<
Do they need to be wrappers of malloc/free? Anway my point was you'd write your own malloc/free implementation in C so what's the problem with writing new/delete?
>3) Error/Exception handling (mean the _almost_ same thing to non-Java/.NET programmers), is also handled by the OS using trap handling and that stuff.<
If they mean almost the same thing does it mean that you cannot handle errors in C++ without the in built exception handling?
>4) Nope, gxx, the GNU C++ compiler, can turn off language features. This is the command line I use to compile the display.cpp file in my OS:
gxx -c display.cpp -ffreestanding -nostdlib -fno-builtin -fno-rtti -fno-exceptions<
Again, I wasn't disputing your statement (insomuch as you can bypass the c/c++ runtime). Your statement that if you are using C++ without the runtime time code then you're using your C++ compiler for C code is rubbish. So far it would seem that just about the only C++ features that you probably wouldn't use are exception handling and rtti as inserting the code to replace the static initialisation is trivial and you'll probably end up coding memory management stuff that you can wrap new/delete around anyway. That leaves quite a lot of C++ features available that aren't available in C should you wish to use them.
Well there is no problem in making new/delete operators. They are just wrappers. The problem is that you'd need to code those functions first (if you want malloc) so one part of your kernel wouldn't have new/delete, therefore you'd use a limited subset of C++.
For the error/exception handling :-D, the try...catch blocks are those that need the OS to intervene because things like #GP (general protection faults) need the OS to read the fault and tell C++ to raise an exception. I'm not sure about normal exceptions that users raise though.
And for using a C++ as a C compiler, well I meant basically as a C compiler. You can still use classes and namespaces and stronger type checking and templates. So yea, using a limited C++ compiler for the kernel is ideal as long as you have a way to initialize global variables. And thats it, so, using C++ is better (my opinion).
Well I'm not sure how you could write an OS and NOT write your own kernel...Quote:
Originally posted by JoeSixpack
>if you want to write everything from scratch? Including the bootloader? Then yeah...you will...(IIRC from when I wrote my OS, anyhow)<
Who said anything about writing something from scratch? You can probably get away with not using asm if you don't write the whole kernal (whatever that is) from scratch. If you wrote the whole thing from scratch then you'd be coding it all in assembler, or writing your own c/c++ compiler.
You really can't escape using a bit of ASM when you write an OS.
Dont confuse C++ exception handling with the exception handling mechanisms for the OS.......they are 2 different things......
You can c++ for writing kernel level code if you have the a compiler that creates the correct code and links to the correct services....whether you can realistically get a good enough compiler for C++ in these circumstances is another matter.....
Looking just at window, the driver programming book written by Edward Dekker (very well regarded) recommends only programing low level windows code in straight C......and points out that at the time of print, Microsoft would not support driver programmers that chose to work in C++.........then in Walter Oney's book (published by MS Press and touted as an authority on WDM - MS's current driver technology) he says to work with C++ modules, but only to enable stuff like declaring variables further into a block and having stronger typecasting (no recommendation on using any of the richer C++ facilities like polymorphism, RTTI etc...)......there are other articles I could point you too where people discuss the merits of C over C++ for low level code and vice versa....so it's hardly a clear issue.....
Oh, and refering to ASM....sure its used a lot in OS developement, but decent OSes like Windows NT will push as much of the ASM code into non portable prts of the OS like the HAL (each architecture would have its own version of the HAL coded by MS in mostly ASM for the chip it would target......) this allows kernel and exceutive code (allong with everything else) to be written in a more portable language like C
>You really can't escape using a bit of ASM when you write an OS.<
This is true, but my point was it wasn't strictly necessary (you'd have a limited kernel though, depending on what your definition of a kernel is and what belongs there).
>Looking just at window, the driver programming book written by Edward Dekker (very well regarded) recommends only programing low level windows code in straight C......and points out that at the time of print, Microsoft would not support driver programmers that chose to work in C++.........<
I believe this again is due to historical factors and the fact that alot of C++ higher level features aren't really necessary when writing something like a driver. This discusses it.