时间戳

首页 > 解决方案 > 编译 typeid(obj) 时会发生什么 - C++

c++ - 编译 typeid(obj) 时会发生什么 - C++

问题描述

我的程序中有一个示例类，如下所示

template<class T>
class MyTemplate1
{
public:
    T a;

    MyTemplate1(T other){
        a = other;
    }
};

在我的主程序中，如果我只是创建 type 的对象MyTemplate1<int>，它不会在 readelf 输出中显示任何 typeinfo 对象。但是如果我添加一些如下代码

MyTemplate1<int> obj = 12;
if(typeid(obj) == typeid(MyTemplate1<float>))
   //some code

readelf 输出显示 typeinfo forMyTemplate1<int>和 typeinfo for MyTemplate1<float>。

$readelf -s -W <objfile> | findstr -I "MyTemplate"
9023: 00000000     8 OBJECT  WEAK   DEFAULT 2899 _ZTI11MyTemplate1IfE
9024: 00000000     8 OBJECT  WEAK   DEFAULT 2894 _ZTI11MyTemplate1IiE

有人可以解释一下这些对象对应什么吗？这些是 MyTemplate1 类的 std::type_info 的全局实例吗？引擎盖下到底发生了什么？

标签： c++clang++rttilibc++

解决方案

您无需构造任何MyTemplate1<T> 在编译单元中实例化的对象，即可在目标文件的全局符号表中查看描述该模板的实例化类的 typeinfo 对象。您只需要参考typeid此类的：-

$ cat main.cpp
#include <typeinfo>

template<class T>
class MyTemplate1
{
public:
    T a;

    MyTemplate1(T other){
        a = other;
    }
};

int main(void)
{
    return (typeid(MyTemplate1<int>) == typeid(MyTemplate1<float>));
}

$ clang++ -Wall -c main.cpp
$ readelf -s -W main.o | grep MyTemplate1
     5: 0000000000000000    16 OBJECT  WEAK   DEFAULT   15 _ZTI11MyTemplate1IfE
     6: 0000000000000000    16 OBJECT  WEAK   DEFAULT   10 _ZTI11MyTemplate1IiE
     7: 0000000000000000    17 OBJECT  WEAK   DEFAULT   13 _ZTS11MyTemplate1IfE
     8: 0000000000000000    17 OBJECT  WEAK   DEFAULT    8 _ZTS11MyTemplate1IiE

$ c++filt _ZTI11MyTemplate1IfE
typeinfo for MyTemplate1<float>
$ c++filt _ZTI11MyTemplate1IiE
typeinfo for MyTemplate1<int>
$ c++filt _ZTS11MyTemplate1IfE
typeinfo name for MyTemplate1<float>
$ c++filt _ZTS11MyTemplate1IiE
typeinfo name for MyTemplate1<int>

这些typeinfo对象在那里，因为正如@Peter 评论的那样，C++ 标准要求typeid引用静态存储持续时间的对象

引擎盖下到底发生了什么？

您可能想知道：为什么编译器将这些typeinfo对象符号设为弱而不是简单的全局符号？为什么它在目标文件的不同部分定义它们？（我的目标文件的第 10 和 15 节，你的第 2894 和 2899 节）。

如果我们检查这些部分中的其他内容：

$ readelf -s main.o | egrep '(10 |15 )'
     5: 0000000000000000    16 OBJECT  WEAK   DEFAULT   15 _ZTI11MyTemplate1IfE
     6: 0000000000000000    16 OBJECT  WEAK   DEFAULT   10 _ZTI11MyTemplate1IiE

我们看到每个对象都是其部分中唯一的东西。为什么这样？

在我main.o的 10 和 15 节中，这些部分是：

$ readelf -t main.o | egrep '(\[10\]|\[15\])'
  [10] .rodata._ZTI11MyTemplate1IiE
  [15] .rodata._ZTI11MyTemplate1IfE

这些中的每一个都是只读数据部分，在以下意义上：

__attribute__((section(.rodata._ZTI11MyTemplate1IiE)))
__attribute__((section(.rodata._ZTI11MyTemplate1IfE)))

它只包含以它命名的对象的定义。

编译器给每个对象一个数据部分给它自己，原因与它制作符号的原因相同WEAK。typeid(MyTemplate1<X>)对任意类型的引用X可能在与.#include的定义相同的链接内的多个翻译单元中进行 MyTemplate1。为了避免在这种情况下出现多重定义错误的链接失败，编译器会弱化符号。链接器将容忍弱符号的多个定义，将所有引用简单地解析为呈现自身的第一个定义并忽略其余定义。通过为每个弱模板实例化符号的定义专用一个唯一的数据段（或适当的函数段），编译器使链接器可以自由 丢弃定义相同弱符号的任何多余的数据或功能部分，而不会对程序造成附带损害的风险。看：

$ cat MyTemplate1.hpp
#pragma once

template<class T>
class MyTemplate1
{
public:
    T a;

    MyTemplate1(T other){
        a = other;
    }
};

$ cat foo.cpp
#include "MyTemplate1.hpp"
#include <typeinfo>

int foo()
{
    return typeid(MyTemplate1<int>) == typeid(MyTemplate1<float>);
}

$ cat bar.cpp
#include "MyTemplate1.hpp"
#include <typeinfo>

int bar()
{
    return typeid(MyTemplate1<int>) != typeid(MyTemplate1<float>);
}

$ cat prog.cpp
extern int foo();
extern int bar();

int main()
{
    return foo() && bar();
}

如果我们编译：

$ clang++ -Wall -c prog.cpp foo.cpp bar.cpp

并像这样链接（带有一些诊断）：

$ clang++ -o prog prog.o bar.o foo.o \
         -Wl,-trace-symbol=_ZTI11MyTemplate1IfE \
         -Wl,-trace-symbol=_ZTI11MyTemplate1IiE \
         -Wl,-Map=mapfile
/usr/bin/ld: bar.o: definition of _ZTI11MyTemplate1IfE
/usr/bin/ld: bar.o: definition of _ZTI11MyTemplate1IiE
/usr/bin/ld: foo.o: reference to _ZTI11MyTemplate1IfE
/usr/bin/ld: foo.o: reference to _ZTI11MyTemplate1IiE

输入bar.obefore foo.o，然后链接器选择 _ZTI11MyTemplate1I(f|i)Efrom的定义bar.o并忽略 in 的定义，将 in 的引用foo.o解析为in的定义。地图文件显示：foo.obar.o

地图文件 (1)

...
Discarded input sections
...
 .rodata._ZTI11MyTemplate1IiE
                0x0000000000000000       0x10 foo.o
...
 .rodata._ZTI11MyTemplate1IfE
                0x0000000000000000       0x10 foo.o
...

中的定义foo.o被丢弃了。如果我们重新链接bar.o和foo.o反转的顺序：

$ clang++ -o prog prog.o foo.o bar.o \
             -Wl,-trace-symbol=_ZTI11MyTemplate1IfE \
             -Wl,-trace-symbol=_ZTI11MyTemplate1IiE \
             -Wl,-Map=mapfile
/usr/bin/ld: foo.o: definition of _ZTI11MyTemplate1IfE
/usr/bin/ld: foo.o: definition of _ZTI11MyTemplate1IiE
/usr/bin/ld: bar.o: reference to _ZTI11MyTemplate1IfE
/usr/bin/ld: bar.o: reference to _ZTI11MyTemplate1IiE

然后我们得到相反的结果。来自的定义foo.o是链接的，并且：

地图文件 (2)

...
Discarded input sections
...
 .rodata._ZTI11MyTemplate1IiE
                0x0000000000000000       0x10 bar.o
...
 .rodata._ZTI11MyTemplate1IfE
                0x0000000000000000       0x10 bar.o
...

里面的那些bar.o被扔掉了。链接器的这种先到先服务原则很好，因为 - 并且仅因为 -template<class T> MyTemplate1编译器在翻译单元foo.cpp中找到的定义与其在其中找到的定义相同bar.cpp，这是 C++ 标准要求的条件，在一个定义规则，但 C++ 编译器无法强制执行。

一般来说，您可以对模板实例化符号进行基本相同的观察，并且您在 clang++ 中看到的内容与您在 g++ 中看到的内容基本相同。

推荐阅读