OSDev.org

The Bare Bones wiki page has this to say about the use of C++ as an OS development language:

OSDev Wiki wrote:Note that not all features from the language is available. For instance, exception support requires special runtime support and so does memory allocation.

Obviously, exceptions are out as there would be no way of handling them without the requisite system infrastructure. But as to memory allocation - what does this affect? Object creation? Mutable objects (std::vector, etc.)? How big is that wrench in the gears?

I'm asking because I'm currently entertaining the idea of using C++ as a potential development language; class/method encapsulation might help me maintain organization and separation of concerns better. However, I'm worried about how much of that language will be unusable without runtime support.

std::vector definitely needs a memory allocator to work, as does anything else that uses new or malloc under the hood. However, even though a memory allocator is probably one of the first things you'll write, those sorts of STL classes probably aren't a great fit for kernel development anyway.

There are two rather different questions hidden in this one.

Your first question is, can I use the language?

Absolutely. There is a lot that C++ brings to the table that is immediately useable: Classes (with their constructor / destructor logic), operator overloading, templates (with all the metaprogramming goodness, if you are into that), the stricter type checking, etc.

The other question is, can I use the standard library?

Here, the answer is a definite "it depends".

Some things will work pretty easily. std::array springs to mind. Others will require some preparation, like std::vector. Others will require a mostly-complete OS to begin with, but I doubt you will have much use for std::iostream in kernel space anyway.

Some caveats:

Licensing. What implementation of the standard library were you thinking of? I do not claim to know them all, but I will daresay they will "expect" a hosted environment and a functional C library to compile. So you will have to make modifications, resulting in a "derived work", which basically disables the licensing exceptions of any GPL'ed implementation (the last time I looked, which admittedly has been a couple of years since).

Adjustments to freestanding. You need to either A) add all the runtime support required for a full library compilation, or B) prune away the parts that rely on unsupported features. Depending on how "maintainable" the library implementation is, this can be easy or real hard. And I am not at all sure if it would be worth the effort.

So, it boils down to the same thing as with C: You can use the language right away. Using the library is a different kettle of fish.

Rusky wrote:std::vector definitely needs a memory allocator to work, as does anything else that uses new or malloc under the hood. However, even though a memory allocator is probably one of the first things you'll write, those sorts of STL classes probably aren't a great fit for kernel development anyway.

So does this restriction also apply to C with anything needing malloc()?

Solar wrote:There are two rather different questions hidden in this one.

Your first question is, can I use the language?

Absolutely. There is a lot that C++ brings to the table that is immediately useable: Classes (with their constructor / destructor logic), operator overloading, templates (with all the metaprogramming goodness, if you are into that), the stricter type checking, etc.

The other question is, can I use the standard library?

Here, the answer is a definite "it depends".

Some things will work pretty easily. std::array springs to mind. Others will require some preparation, like std::vector. Others will require a mostly-complete OS to begin with, but I doubt you will have much use for std::iostream in kernel space anyway.

Some caveats:

Licensing. What implementation of the standard library were you thinking of? I do not claim to know them all, but I will daresay they will "expect" a hosted environment and a functional C library to compile. So you will have to make modifications, resulting in a "derived work", which basically disables the licensing exceptions of any GPL'ed implementation (the last time I looked, which admittedly has been a couple of years since).

Adjustments to freestanding. You need to either A) add all the runtime support required for a full library compilation, or B) prune away the parts that rely on unsupported features. Depending on how "maintainable" the library implementation is, this can be easy or real hard. And I am not at all sure if it would be worth the effort.

So, it boils down to the same thing as with C: You can use the language right away. Using the library is a different kettle of fish.

How does std::string typically fare in terms of usability out of the box?

The reason I was intending to use C++ as a development language is mainly due to linguistic features, so I don't necessarily need to start sweating if many of the STL containers aren't immediately available. My line of thinking was that the class/object model of C++ might help maintain better code density and clarity (although C is my first language, so I could use it as well).

Probably was planning on using llvm-clang's libc++; now that you refresh me on things like iostream and what-not I might just try to brew my own STL container namespace. Implement the ones I need as I need them and just hardwire down to the kernel.

physecfed wrote:So does this restriction also apply to C with anything needing malloc()?

It does. The standard user-space malloc won't work because it expects to be able to make a system call to get memory to carve up. You need to supply a malloc replacement that works in your kernel if you want to use, for example, strdup(). Lot's of libc requires malloc, including some parts of stdio.

physecfed wrote:How does std::string typically fare in terms of usability out of the box?

Same situation. Usually uses new internally which sits on malloc().

physecfed wrote:Probably was planning on using llvm-clang's libc++; now that you refresh me on things like iostream and what-not I might just try to brew my own STL container namespace. Implement the ones I need as I need them and just hardwire down to the kernel.

I ported libc++ to my OS and found it fairly difficult to deal with. I was unable to get it to build a cut-down version. It needed wchar support, locale support and a working stdio just to compile. I couldn't see any way to use libc++ in a kernel. Gcc's libstdc++ compiles and runs without those things but is still awkward to use in a kernel.

gerryg400 wrote:

physecfed wrote:So does this restriction also apply to C with anything needing malloc()?

It does. The standard user-space malloc won't work because it expects to be able to make a system call to get memory to carve up. You need to supply a malloc replacement that works in your kernel if you want to use, for example, strdup(). Lot's of libc requires malloc, including some parts of stdio.

physecfed wrote:How does std::string typically fare in terms of usability out of the box?

Same situation. Usually uses new internally which sits on malloc().

physecfed wrote:Probably was planning on using llvm-clang's libc++; now that you refresh me on things like iostream and what-not I might just try to brew my own STL container namespace. Implement the ones I need as I need them and just hardwire down to the kernel.

I ported libc++ to my OS and found it fairly difficult to deal with. I was unable to get it to build a cut-down version. It needed wchar support, locale support and a working stdio just to compile. I couldn't see any way to use libc++ in a kernel. Gcc's libstdc++ compiles and runs without those things but is still awkward to use in a kernel.

I was more meaning just creating a container namespace; just things like std::string, std::vector, etc., hardwiring the logic to the kernel for use in other parts.

physecfed wrote:I was more meaning just creating a container namespace; just things like std::string, std::vector, etc., hardwiring the logic to the kernel for use in other parts.

I'm not sure what you mean. Do you mean to use std::string and std::vector in userspace but implement support in the kernel ?

gerryg400 wrote:

physecfed wrote:I was more meaning just creating a container namespace; just things like std::string, std::vector, etc., hardwiring the logic to the kernel for use in other parts.

I'm not sure what you mean. Do you mean to use std::string and std::vector in userspace but implement support in the kernel ?

I mean having access to those container types in the kernel, for data structures and stuff of that nature.

physecfed wrote:

gerryg400 wrote:

physecfed wrote:I was more meaning just creating a container namespace; just things like std::string, std::vector, etc., hardwiring the logic to the kernel for use in other parts.

I'm not sure what you mean. Do you mean to use std::string and std::vector in userspace but implement support in the kernel ?

I mean having access to those container types in the kernel, for data structures and stuff of that nature.

Ah, then the answer is no. You won't have access to std::string or std::vector them until you do significant work in your kernel.

May I ask which libc you intend to use ?

gerryg400 wrote:Ah, then the answer is no. You won't have access to std::string or std::vector them until you do significant work in your kernel.

May I ask which libc you intend to use ?

That's fair. Since I've thought of the idea, I've since reconsidered it seeing that even if I managed to implement a minor C++ container library for the kernel, it would result in separate sections of the kernel adhering to one of two different container methodologies. That doesn't bode well for maintenance.

As to libc, I'm assuming you mean which libc variety I plan on implementing in the kernel itself - I'll probably write my own implementation of the POSIX C library (as I'm trying to build a *nix-related OS) and add in features of cstdlib where needed.

Slight aside - regarding your signature - out of interest, where'd you find that? I recognized it from a very old copy of UNIX for Dummies of mine that has a slightly-different wording.

You should also absolutely be aware of the C++ runtime which you are required to implement if you want to take advantage of all features. If your OS is linux-like, you can probably port libsupc++. This is if you are lucky enough to have chosen G++ as a compiler. Myself, I decided to a) write a completely independent OS, and b) use the Visual C++ compiler. Almost zero documentation on that, but it works now.

Basically, you need the RTTI (Runtime Type Information) to do things like dynamic_cast<T>(), and typeinfo() stuff. Also, if you want to use exceptions, you need to implement a runtime for that as well.

If you're not into that, and will never use polymorphic classes with virtual methods which you want to cast to their derived classes, you can disable RTTI. (-fno-rtti in G++, /GR-). This does allow you to perform basic polymorphism.

EDIT: Maybe this provides a little insight http://www.codingunit.com/cplusplus-tut ... -type_info

dseller wrote:You should also absolutely be aware of the C++ runtime which you are required to implement if you want to take advantage of all features. If your OS is linux-like, you can probably port libsupc++. This is if you are lucky enough to have chosen G++ as a compiler. Myself, I decided to a) write a completely independent OS, and b) use the Visual C++ compiler. Almost zero documentation on that, but it works now.

Basically, you need the RTTI (Runtime Type Information) to do things like dynamic_cast<T>(), and typeinfo() stuff. Also, if you want to use exceptions, you need to implement a runtime for that as well.

If you're not into that, and will never use polymorphic classes with virtual methods which you want to cast to their derived classes, you can disable RTTI. (-fno-rtti in G++, /GR-). This does allow you to perform basic polymorphism.

EDIT: Maybe this provides a little insight http://www.codingunit.com/cplusplus-tut ... -type_info

I understand the concepts of runtime type-checking, but I'm beginning to get the idea that porting C++ to the userland is going to be rather like Pandora's box.

dseller wrote:You should also absolutely be aware of the C++ runtime which you are required to implement if you want to take advantage of all features. If your OS is linux-like, you can probably port libsupc++. This is if you are lucky enough to have chosen G++ as a compiler. Myself, I decided to a) write a completely independent OS, and b) use the Visual C++ compiler. Almost zero documentation on that, but it works now.

Basically, you need the RTTI (Runtime Type Information) to do things like dynamic_cast<T>(), and typeinfo() stuff. Also, if you want to use exceptions, you need to implement a runtime for that as well.

If you're not into that, and will never use polymorphic classes with virtual methods which you want to cast to their derived classes, you can disable RTTI. (-fno-rtti in G++, /GR-). This does allow you to perform basic polymorphism.

EDIT: Maybe this provides a little insight http://www.codingunit.com/cplusplus-tut ... -type_info

Have you implemented support for the VC++ abi? Do you have any repository I could check (and mind sharing) ? I had totally given up because of the lack of documentation

physecfed wrote:I understand the concepts of runtime type-checking, but I'm beginning to get the idea that porting C++ to the userland is going to be rather like Pandora's box.

Actually no. If you have a Posixy libc and a Posixy kernel then you will have no trouble supporting gcc's libstdc++ in userspace. There is almost no OS support required other than the standard Posix interfaces like open(), read(), write() etc. and a few other bits and pieces like atexit(). The so-called advanced features like rtti and exceptions work fine with almost no help from the OS other than that required by libc.

The reason we say that it's difficult to use the entire of libstdc++ in your kernel is that you need a libc that works in your kernel. This is difficult (i.e. lots of time and knowledge required) because a lot of required libc pieces which are designed to be used in userspace are more difficult to use in kernel space. For example, any libc function that might make a system call needs to be rewritten in such a way that it works 'within the system' and not outside it. Furthermore, the C++ runtime will, depending on which is chosen, need kernel-side replacements for concepts like mutexes, condvars, exit(), atexit(), stdin, stdout, stderr, environment variables, locale, new, delete and mmap. In other words it is much quicker and easier to write your own string class than to use the libstdc++ one.

Use D as a development language.

Here is example https://github.com/Rikarin/Trinix