Page 1 of 1
Why only std%.h and not cstd% (g++)?
Posted: Thu Jan 27, 2011 8:20 pm
by 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?
Re: Why only std%.h and not cstd% (g++)?
Posted: Fri Jan 28, 2011 4:31 am
by 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).
Re: Why only std%.h and not cstd% (g++)?
Posted: Fri Jan 28, 2011 7:59 am
by Owen
Solar wrote: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.
Re: Why only std%.h and not cstd% (g++)?
Posted: Fri Jan 28, 2011 9:44 am
by Solar
You are right of course, I got it the wrong way around. Sorry for being that wide off the mark.
Re: Why only std%.h and not cstd% (g++)?
Posted: Sun Feb 13, 2011 8:26 pm
by 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.
Re: Why only std%.h and not cstd% (g++)?
Posted: Mon Feb 14, 2011 1:43 am
by 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.
Re: Why only std%.h and not cstd% (g++)?
Posted: Mon Feb 14, 2011 5:51 pm
by TylerH
Combuster wrote: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.