That's interesting - the standard does say that (17.4.1.1. Library contents)
All library entities except macros, operator new and operator delete are defined within the namespace std or namespaces nested within namespace std.
And clearly says that (5.2.8 Type identification)
The result of a typeid expression is an lvalue of static type const std::type_info (18.5.1) and dynamic type const std::type_info or const name where name is an implementation-defined class derived from std::type_info which preserves the behavior described in 18.5.1.
Ans, of course, the descriptin of header <typeinfo?>
indicate the it should be in namespace std
(18.5 Type identification):
Header <typeinfo>
synopsis
namespace std {
class type_info;
class bad_cast;
class bad_typeid;
}
So type_info
should be in the std
namespace (and not outside of it). I guess that either this is a bug or there's some large set of code (or small set of important code) that needs it outside of the std
namespace. I'd have thought they'd use some preprocessor magic to make it so you could force it to be in the std
namespace if desired (or the other way around - make it in std
by default and allow a macro or something to force it to the global namespace).
However, one additional wrinkle for type_info
is that it's the result of the typeid
operator (more precisely, something derived from type_info
is the result), so there's probably a tight dependency on what the compiler does for the typeid
operator that the library needs to be in line with. So the fact that type_info
isn't in namespace std
is possibly due to what the compiler does with typeid
expressions, and the library writers probably have little direct control over that (and I'd guess that's one reason why there's no preprocssor workaround for the problem). Someone who knows a lot more about how compilers work than I do would have to explain this better (or take it beyond speculation).
But I think you'll have to ask someone at Microsoft (or PJ Plauger/Dinkumware) for a real answer to "why".