为什么 type_info 在命名空间 std 之外声明？

发布于 2024-08-10 21:29:43 字数 224 浏览 1 评论 0原文

我正在使用 VS2005 和 STL 的 MS 实现。然而，类 type_info 是在“命名空间 std”之外声明的。这会给第三方库带来一些问题，除了查找 std::type_info 之外。为什么会这样，有什么解决办法吗？这是 typeinfo 开头的示例：

class type_info {
...
};


_STD_BEGIN // = namespace std  {

原文

I'm using VS2005 and the MS implementation of STL. However, the class type_info in is declared outside of "namespace std". This creates some problems for third party libs that excepts to find a std::type_info. Why is this so, and is there any workaround? Here is a sample from the beginning of typeinfo:

class type_info {
...
};


_STD_BEGIN // = namespace std  {

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

戒ㄋ 2024-08-17 21:29:43

这很有趣 - 标准确实这么说（17.4.1.1. 库内容）

除宏、operator new 和operator delete 之外的所有库实体均在命名空间 std 或嵌套在命名空间 std 中的命名空间内定义。

并明确指出（5.2.8 类型识别）

typeid 表达式的结果是静态类型 const std::type_info (18.5.1) 和动态类型 const std::type_info 或 const name 的左值，其中 name 是从 std::type_info 派生的实现定义的类它保留了 18.5.1 中描述的行为。

当然，头文件的描述表明它应该位于命名空间 std 中（18.5 类型标识）：

标题概要

命名空间 std {
    类类型信息；
    类 bad_cast；
    类 bad_typeid；
}

因此，type_info 应该位于 std 命名空间中（而不是在其外部）。我猜想这要么是一个错误，要么是在 std 命名空间之外有一些大型代码（或小型重要代码）需要它。我本以为他们会使用一些预处理器魔法来制作它，这样您就可以根据需要强制它位于 std 命名空间中（或者相反 - 使其位于 std< /code> 默认情况下并允许宏或其他东西将其强制到全局命名空间）。

然而，type_info 的另一个问题是它是 typeid 运算符的结果（更准确地说，是从 type_info 派生的结果），因此，可能紧密依赖于编译器对库需要符合的 typeid 运算符所做的操作。因此，type_info 不在命名空间 std 中的事实可能是由于编译器对 typeid 表达式所做的操作，并且库编写者可能有对此几乎没有直接控制（我猜这就是为什么没有针对该问题的预处理器解决方法的原因之一）。比我更了解编译器如何工作的人必须更好地解释这一点（或者超越猜测）。

但我认为你必须向 Microsoft（或 PJ Plauger/Dinkumware）的某个人询问“为什么”的真正答案。

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".

回复收藏 0 原文