How is it checked on runtime?Runtime-checked cast:
One way to learn C++ is to use itUntil you really understood C++, you should stick to C.
I will try to copy the necessary data to a struct in the C code and then access the struct instead of a class. Is this a good idea?I second Pype's urgent advice not to assume the binary layout of a class. Use accessor functions!
Absolutely, but it's better to learn in a nice, controlled environment with good debuggers and runtime support, and not as a basis for your own OS. Learning the language while you write an OS is a pretty bad idea, as you will have to keep starting again as you learn that what you have already written is wrong. What's more, not knowing the language makes it hard to come up with a detailed design beforehand.Adek336 wrote:One way to learn C++ is to use it
Code: Select all
class Foo
{
Foo();
int x;
int y();
}
Code: Select all
int z;
int Foo::*bar;
int (Foo::*baz)();
Foo quux;
Foo *gah;
gah = new Foo();
bar = &Foo::x;
baz = &(Foo::y)();
gah->*bar = 5;
quux.*bar = gah->*baz();
z = quux.*baz();
}
Adek336, I salute your courage.Adek336 wrote: I find learning C++ in osdev more interesting so I try my best to keep it working in C++ instead of C.
lol, thanxAdek336, I salute your courage.
I'm into C++ since 2 weeks, nowI mean, I know the C language and most of its standard lib inside out. I consider myself being quite proficient in C++. I know most of the more arcane "dark places" of the C++ language, I've written (and debugged and refactored) tons of C++ code, I've read stuff about the ABI, runtime requirements, and implementation details that probably would make your toenails curl. I discuss stuff with a language lawyer and C++ Standards Committee member for fun in my lunch breaks.
Thanx - cool!I just had to say that - respect!
Just to throw in my 2 cents.Tim Robinson wrote: In any case, any speed increase you might get from writing your scheduler in assembly is going to be tiny compared to the overhead imposed by the kernel-user transitions, and virtually zero compared to the period between calls to the scheduler.
Before you look at whether you can save a couple of clock cycles by writing your scheduler in Assembler, check the Algorithm of your scheduler, its complexity. What happens to the scheduler execution times when the number of tasks in your queues increases? How does it scale?Tim Robinson wrote: In any case, any speed increase you might get from writing your scheduler in assembly is going to be tiny compared to the overhead imposed by the kernel-user transitions, and virtually zero compared to the period between calls to the scheduler.
*gg* I for my part am happy to master C at the moment.That's called "data hiding". Let's say your data is held in a data structure X. Later, you realize that data structure Y would be better.beyond infinity wrote: If a class is considered to be "something like a c structure", then why not putting the pointer to the desired incarnation of the class in a from-asm-accessible-pointer-variable, and manipulating the desired memory location by using some neat offsets into the object.
Well, compared to Adek, at least I know the language...@Solar: you've guts, gosh, to do a kernel in c++.
Once you have malloc() and free(), operator new() and delete() is trivial. Templates don't need runtime support, neither do classes or inheritance (unless they are instantiated globally / statically, but that is handled with 10 lines of code). That's all handled by the compiler...writing all that extra runtime mumbojumbo needed to have classes, inheritance, templates and new and delete and co ...
It doesn't mean I cannot use both C-like and C++ constructs. I'm sure I'll have the best os around here ;DWell, compared to Adek, at least I know the language...
