Page 1 of 1

C++ kernel programming with RTTI

Posted: Fri Feb 27, 2004 7:29 am
by Candy
Does anyone have any experience with this? Does anybody have some info pointers?

Do you need RTTI for polymorphism?

How is RTTI handled by GCC (3.3.*) ?

Re:C++ kernel programming with RTTI

Posted: Fri Feb 27, 2004 7:49 am
by Pype.Clicker
http://www.codesourcery.com/cxx-abi/
http://www.informit.com/isapi/guide~cpl ... ontent.asp

Afaik, RTTI isn't required for polymorphism, but only for <dynamic cast> operator ...

Re:C++ kernel programming with RTTI

Posted: Fri Feb 27, 2004 8:09 am
by Solar
No experience on my part. I'd daresay you don't need RTTI - or rather, if you need it, it's probably a sign that your design is screwed up...

As much as I understand your desire to have all bells & whistles enabled up front - hell, I've been there myself a year or so ago - I'd advice you start without RTTI enabled, and see whether this poses to be a problem at all for your kernel.

Re:C++ kernel programming with RTTI

Posted: Sat Feb 28, 2004 7:52 pm
by libber
Not just synamic cast, but also catch and throw and and a few others i believe. I also don't think you need RTTI. but to get RTTI working you need a few libraries like libgcc_s and more importantly libstdc++.

Re:C++ kernel programming with RTTI

Posted: Mon Mar 01, 2004 4:24 am
by Pype.Clicker
libstdc++ for RTTI and exception handling ?? i wouldn't bet on this ... If you have any evidence things are so, i'd be interrested.

Re:C++ kernel programming with RTTI

Posted: Mon Mar 01, 2004 5:09 am
by Solar
He probably meant libsupc++ - libstdc++ is the standard library, i.e. streams, STL and stuff.

I haven't delved into the portability of libsupc++ myself, yet, but if that's of a breed similar to glibc, I'll pass, thank you. ;-)

Re:C++ kernel programming with RTTI

Posted: Mon Mar 01, 2004 5:41 am
by Candy
Solar wrote: He probably meant libsupc++ - libstdc++ is the standard library, i.e. streams, STL and stuff.
That doesn't explain the name not being libstl or libstlc++, the absence of every iterator and collection, and the presence of a number of files starting with eh* and files like rtti.cpp
I haven't delved into the portability of libsupc++ myself, yet, but if that's of a breed similar to glibc, I'll pass, thank you. ;-)
can tell, yup, it's as clear as gold (gold has a very high density, and is not clear, if you didn't guess it). Tried to read a part of it, but I happened to print the wrong pages (headers of 20 pages with three lines of interest: inclusion of a different header, 19.9 pages for the old format, one inclusion of a DIFFERENT file for the content with the actual c++ format, and the end-of-file line...

Re:C++ kernel programming with RTTI

Posted: Mon Mar 01, 2004 5:48 am
by Solar
Candy wrote: That doesn't explain the name not being libstl or libstlc++...
Common misconception: The STL is a subset of the C++ standard library. There are parts of the standard library that have nothing to do with the STL.
...the absence of every iterator and collection...
I haven't looked at the internals of either lib yet, but you are aware that both iterators and collections would be defined in headers, since they are templates which - pending support for the "export" keyword in gcc - can't split declaration and definition?
...and the presence of a number of files starting with eh* and files like rtti.cpp
Exception handling is a bloody, compiler-implementation-dependent mess. :(

Re:C++ kernel programming with RTTI

Posted: Mon Mar 01, 2004 5:59 am
by Candy
Solar wrote: Common misconception: The STL is a subset of the C++ standard library. There are parts of the standard library that have nothing to do with the STL.
uh... ok... Still don't expect it to be there.
...the absence of every iterator and collection...
I haven't looked at the internals of either lib yet, but you are aware that both iterators and collections would be defined in headers, since they are templates which - pending support for the "export" keyword in gcc - can't split declaration and definition?
There were some big-@$$ files in there (hundreds of K's), must admit I didn't even give them a look. Will look tomorrow.
Exception handling is a bloody, compiler-implementation-dependent mess. :(
So true. It was indeed a mess... Did you call 112 yet (or 0900-8844 if it isn't urgent)?

Translation for those nonconforming USers: 112 is the european 911.