为什么type_info :: name（）未指定？

我完全知道std::type_info::name()的返回值是由实现定义的。为什么type_info :: name（）未指定？

从C++标准（ISO/IEC 14882：2003§18.5.1.7）：

返回：实现定义NTBS。

我的问题是：为什么？如果标准决定返回值应该是什么，这个成员函数是不是更有用？

来源

2010-08-25 Job

+1对于这种好奇。我想，答案是给我想一些编译器的空间。 – Chubsdad 2010-08-25 08:52:43

既然你不能在编译器之间混合使用二进制文件，那么只要它在编译器中是一致的，这并不是什么大问题。 – 2010-08-25 15:15:45

基本上，如果实施决定他们不能或不想支持RTTI，他们可以只需return "";。如果标准强制它返回某些东西，那么它们可能会杀死任何具有RTTI资源不存在或想要被禁用的环境的兼容编译器的能力（例如，微芯片）。

我们不要忘记我们不想在任何编译器上强制使用ABI /名称修改机制。

这遵循C++哲学“你不需要为你不需要的东西付钱”。

来源

2010-08-25 08:50:31 GManNickG

对于RTTI参数为+1。但是不能标准规定类似*返回如果支持RTTI的动态类型的未加密名称，如果不是*则返回静态类型？ – Job 2010-08-25 09:31:31

@作业：可能，但如何格式化类型名称？字符串存储在哪里？我同意有一个或者至少可靠的'name（）'结果是很好的，但是鉴于编译器的性质，未指定是最好的。（他们如何处理类型是他们的业务，我们不能确定他们如何处理它，以及目标平台是什么，以及这些是否允许有意义的'name（）'结果。） – GManNickG 2010-08-25 09:44:57

我认为'0' isn是一个有效的NTBS，所以这样的实现至少应该返回“'”。 – sbi 2010-08-25 10:11:10

我们在谈到供应商返回不同字符串时，我认为这只是一种“我们这样做，您改变”，“不，我们这样做，您改变”编译器供应商之间的事情。即使是标准委员会也不想惹恼编译器团队，并且创建一些不被任何供应商采用的中立的新标准往往意味着找到无论如何都无意义的东西。

为什么他们不是所有明显的命名空间::类::函数等已经？一些当前的实现可能历来发现使其匹配链接器所需的错位名称，偏执（或具有偏执的客户端）重新使用存储器等等是方便的。

来源

2010-08-25 08:53:50

为什么type_info :: name（）未指定？

回答

相关问题