I´m a beginner in Os development. I searched for a tutorial about writig a kernel in C++ and I found the one from Osdever.net. But the link to the tutorial doesn´t work. So I downloaded the .pdf-file.
The author wrote in the introduction that the tutorial has 7 parts. But in the .pdf-file are only 2.
Is here anyone who has the complete tutorial or knows another link?
C++ Kernel Tutorial
Could be 7 parts were planned, and only 2 written. That's not too uncommon around here...
But basicly, you need to do the same as you'd do for a C kernel, and then implement support for global constructors, new/delete, exceptions, and rtti (which ever of the above you need) manually. If you don't use the above (and compile with -fno-exceptions -fno-rtti flags in case of GCC), then you can start exactly if you were writing in C (just remember to use extern "C" when you need to know the name of a C++ function in assembler).
As for new/delete, you can write a C-style malloc, and then write the operators on top of that. There's lots of info about doing that around the internet, because it's not too uncommon for people to want to overload those in normal application development (for purposes of special casing, or debugging).
Global constructors/destructors are a bit tricky in kernel, because you need more guarantees about their order than C++ typically gives you. Might be easier just to build without them. If you need exceptions/rtti, that's probably the biggest work. How you do them depends on the compiler you are using.
That's about it. It's shouldn't be too different from a C kernel after all.
But basicly, you need to do the same as you'd do for a C kernel, and then implement support for global constructors, new/delete, exceptions, and rtti (which ever of the above you need) manually. If you don't use the above (and compile with -fno-exceptions -fno-rtti flags in case of GCC), then you can start exactly if you were writing in C (just remember to use extern "C" when you need to know the name of a C++ function in assembler).
As for new/delete, you can write a C-style malloc, and then write the operators on top of that. There's lots of info about doing that around the internet, because it's not too uncommon for people to want to overload those in normal application development (for purposes of special casing, or debugging).
Global constructors/destructors are a bit tricky in kernel, because you need more guarantees about their order than C++ typically gives you. Might be easier just to build without them. If you need exceptions/rtti, that's probably the biggest work. How you do them depends on the compiler you are using.
That's about it. It's shouldn't be too different from a C kernel after all.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Most features that make C++ more attractive than C, are actually just stuff that compiler handles automatically for you. Unless I forget something, it's just new/delete, global constructors/destructors, exceptions, and RTTI that actually need some external support.Tyler wrote:Well one would hope it was at least as different as one wants it to be, or it really might not be worth the effort...
Methods (virtual or not), templates, and stuff like that, need at most some support from the linker. At runtime they act mostly like if you wrote the same functionality manually in C.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
If you use pure virtual functions you need one supporting function in g++, that handles the case that this function was not overloaded in some derived class. But that function is normally not called and afaik it requires some hackery, because the C++ compiler won't let you create instances of classes, where pure virtual functions weren't overridden.
I guess it's needed because if you have a class with a pure virtual, and then inherit with another class, with incompatible (say old) version of the headers (as could happen with shared libraries), it might happen that you actually end up with a reference to the non-overriden pure virtual.
One way to handle it, would simply be to store 0 into the vtable, and let the program crash with pagefault, but a cleaner solution is to use a helper function that catches the problem, so you can have a nice error message. GCC obviously takes the latter approach.
One way to handle it, would simply be to store 0 into the vtable, and let the program crash with pagefault, but a cleaner solution is to use a helper function that catches the problem, so you can have a nice error message. GCC obviously takes the latter approach.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.