PHOTOOG Photography writings by Olivier Giroux


The deal with typeid( … ).name( )

Chalk up one more day of productivity to the loose ends of language standardization. Today's source of pain is the type_info::name...

What's wrong with it? -- it's completely compiler-specific. I've always known this, but the limitations never bogged me until today.

By and large, I would say Visual C++ does the right thing here. It gives you a human-readable name that's actually a valid C++ type declaration. That's what I'd naturally expect, though I'd like it better if it were a bit less verbose.

What about GCC? First they give you their decorated version and you need to use their helper library to undecorate it. But the insulting part is that the __cxa_demangle API can't undecorate all names that type_info::name will give you, particularly if you mix modules compiled with (even subtly) different revisions of the compiler. This is the part that caused new pain for me, as the two GCC versions are so closely related I didn't even think it could be an issue.

This continues the long legacy of Linux "source-level" compatibility, where you need to recompile the whole world with a new compiler whenever one of your components is updated.

I did manage to work my way out of this mud pit, but like many times before, I've ended up with another thousand-line meta-program that's sure to raise eyebrows if it ever becomes an issue. Yarlch. :^(

Some good came out of this though, my solution ended up being portable, and as clean but less verbose than the VC++ solution. It is very limited in scope though (basic types, STL types, boost tuples and unlimited combinations of the same).

Filed under: Uncategorized Leave a comment
Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

No trackbacks yet.