OSDev.org

I wrote what could be called a "Multiboot barebones" - a kout global object used by a main() to print the values from the multiboot data structure, nothing more.

The beauty of "cout << whatever" was a clear winner in my book, because you didn't have to do any format string parsing or whatnot to make it work, and extending kout with another data type was dead simple, too. I strongly believe similar benefits can be had in many other parts of the kernel.

Another strong point is that, with C++, it becomes quite natural to keep data structure definitions and the code handling those structures together, something that requires a conscious effort to do in C.

And in the end, any good C code I have seen so far is effectively object oriented anyway, so why not use a language that supports this with additional syntactic suggar that doesn't cost you anything (if used correctly)?

Standard disclaimer, your mileage might vary.

My kernel has always been object oriented, so converting to C++ seemed like a good idea. I don't regret it, everything is so much cleaner with classes. Pure virtual functions are a very powerful concept too, which greatly simplify IO in my opinion.

I've implemented support for new/delete and global objects quite easily. I'd love to have exceptions support, but I don't know where to start!

I would consider writing for C++ if someone wrote a linker designed to reduce need for any kludges to get it started. I feel that using the Ctor/Dtor section is a bit irrelevant in OS Development.

I do like Object-Oriented Designs though, especially as you find most OS' built into obviously Classable Chunks, even going as far as having sets of functions with identical prefixes, seems a bit silly to not use Classes.



Perhaps it is your problem? You don't seem to be able to concentrate on a post long enough to realise i was making a point about his obviously marketed comments about Alcohol, not about his analogy which was fine. Had i had a problem with the analogy i would have made another one, perhaps that it is more like Water... free of as many additivs as possible, and different around the world.

Also... i don't smoke Marijuana, despite my mothers attempts for me to start, but you don't have to take something to fight against the lies surrounding it. I don't like Windows or Linux, but if you make false comment's about them then i will attempt to enlighten you. You can use your word for me, it will probably just **** it out, but best to get it out there.

I started learning C++ first. I definitely think it is easier to manage linked list in C++ than in C. Id like to create a kernel in C++, but i just can't seem to get pre-settings right (-nostartfiles, etc.)

usually works for me

eCOS is written in C++. (Though there's a bit of C and ASM in it).

You can simulate namespaces by carefully stripping and partially linking object files... although, it won't provide you with the neat code look.

JJ

Yeah why do we need global object construction and destruction in OS development. Are you kidding?

Example: global object 'cout', or 'console'

The language used for any kind of development is really almost irrelavent as far as performance is concerned, as long as it (a) compiles to native machine code and (b) doesn't require ridiculous amounts of runtime support. It's more about the *algorithms* you choose to implement.
Remember from coding theory that it's the order of an algorithm (e.g. O(log(n)) ) that counts most. The leading constant, which will be what is determined by the language/compiler choice (unless one compiler performs tail recursion->iteration optimisations and one doesn't) doesn't make that much of a difference.

And you don't *need* global objects. They can be useful, but take the following case (as in my OS, but I *do* use global objects )


The only disadvantage is your 'global objects' must be pointers, but that shouldnt really matter. In this case they are initialised, stored on the stack then the kernel is run. As far as the kernel is concerned those global pointers are initialised.

JamesM

@JamesM
This is a dangerous form of programming consider the following code:


Though it very obvious that this is faulty programming, as the object is destroyed on exitting init. It is possible with your solution of having pointers to global objects. Furthermore every access to the global object now uses an additional memory dereference, therefore adding code and decreasing performance albeit little. In short if you want global objects then declare them as such. In your case you don't have global objects you have global pointers to objects and that is something different.

Fair point about the performance penalty. I was suggesting this method as an alternative workaround, not as the best possible solution (As mentioned, I use proper globals myself)



In most cases it would be dangerous. However in an OS it is known that the first and ONLY function that is ever called is _main(). Therefore it is safe to do any pointer initialisation there. Unless the stack gets corrupted or VM space gets changed, it's safe. Again though, it's not optimal and I know it!

JamesM

Well, but it is not wise to create them on the kernel stack, because you reuse this stack in every interrupt and syscall and possibly overwrite your objects. It is better to use new/delete then and store this objects on the heap.... but real global objects are still better.

Couldn't you just create global variables through static members? Like:

Then to call it:

Thats called the singleton pattern and is one method of having global variables. In a proper C++ environment you should have no global variables only objects and pointers to objects:



Creating objects on a specific location as for the APIC can be done via a Singleton pattern if there is only one. Remember to use the placement new (see wiki) to instanciate the object. As you can see there are no global variables only the root object kernel and its components.