Why only std%.h and not cstd% (g++)?

[TylerH]

I built an i686-elf GCC cross compiler with C++ support enabled, as described here http://wiki.osdev.org/GCC_Cross-Compiler, and went to use the same headers installed by default, but with the customary C++ name transformation, to find they are not there. An example would be how I can use stdint.h, but not cstdint. Is there a way to install them with GCC?

[Solar]

The C++ style headers (like <cstdio>) are merely wrappers around the C style headers, putting all identifiers contained therein into the std:: namespace. You can quite literally get away with this:

Code: Select all

// <cstdio>

namespace std {

#include <stdio.h>

}

Organisatorily, the C++ style headers are part of the C++ standard library. The C++ support you enabled in GCC in the tutorial refers only to the compiler, not the library (as there is none).

[Owen]

The C++ style headers (like <cstdio>) are merely wrappers around the C style headers, putting all identifiers contained therein into the std:: namespace. You can quite literally get away with this:

Code: Select all

// <cstdio>

namespace std {

#include <stdio.h>

}

Organisatorily, the C++ style headers are part of the C++ standard library. The C++ support you enabled in GCC in the tutorial refers only to the compiler, not the library (as there is none).

Whoa whoa whoa! That will most certainly not work.

Think: What happens when you do

Code: Select all

#include <cstdio>
#include <stdio.h>

int main(int argc, char** argv)
{
    printf("Hello\n");
}

in that case?

Answer: undefined symbol printf

The totally correct way it to have some headers, shared by the C and C++ libraries, which have no header guards and can be used to import the C stuff into both the std and global namespaces by the std*.h and cstd* headers. The acceptable but leaky way for the cstd* headers to include the corresponding std*.h header and then do an asstonne of using declarations. This is what libstdc++ does.

[Solar]

You are right of course, I got it the wrong way around. Sorry for being that wide off the mark.

[TylerH]

Which STL/C++ libc would be easiest to port? Assuming I'm going to leave out all IO and other stuff obviously inapplicable for a kernel.

[Combuster]

I don't think any one of them is going to be trivial - you'll need to patch them all off to cover for your lack of C library functionality on which they will depend. You should at least have a working standards-compliant malloc() - if you don't you might even better be off writing your own STL containers that can work with whatever kernel allocator you use.

[TylerH]

I don't think any one of them is going to be trivial - you'll need to patch them all off to cover for your lack of C library functionality on which they will depend. You should at least have a working standards-compliant malloc() - if you don't you might even better be off writing your own STL containers that can work with whatever kernel allocator you use.

Actually, I was going to get the STL for my base classes, and implement my kernel interfaces around that. For example, my memory management would be a subclass of std::allocator.