在当前的 C++ 草案(2019 年 8 月)中,pp-import http://eel.is/c++draft/cpp.import#nt:pp-import的语法允许pp-tokens在header-name或header-name-tokens.
该部分的当前版本是P1703的结果:“Recognizing Header Unit Imports Requires Full Preprocessing”。在此提案引起的变化之前,语法仍然允许预处理header-name或之后的标记标记header-name-tokens,但以 a 的形式pp-import-suffix。(第[cpp.module] P1103)。
在这种情况下允许额外的、未使用的预处理令牌背后的原因是什么?
谢谢你。
在C++标准的basic.life部分,可以找到以下内容(强调我的):
类型T的对象o的生命周期结束时:
如果T是具有非平凡析构函数([class.dtor])的类类型,则析构函数调用将启动,或者
对象占用的存储被释放,或被未嵌套在o中的对象重用([intro.object]).
我试图找到对象的存储示例o被嵌套在o中的对象重用(与标准所说的相反).
首先,我需要确保我理解标准的含义是"对象占用的存储被嵌套在o中的对象重用".首先,为了重用存储,必须创建一个新对象.其次,为了重用o的存储,必须在o使用的内存位置创建新对象.最后,必须在一个内存位置创建新对象,该位置将使新对象"嵌套在o中",例如在已经存在的对象"nesten in o"的位置.它是否正确?
我想到了一些例子,例如:
工会会员:
union U { double d; int n; }; U u = {1.0}; new (&u.n) int;
Run Code Online (Sandbox Code Playgroud)在chars数组中创建的对象:
char mem[sizeof(int)];
new (mem) int;
Run Code Online (Sandbox Code Playgroud)这些是正确的吗?还有其他例子吗?
谢谢.
C ++标准的当前草案(2019年3月)具有以下段落([basic.types] p.4)(重点是我的):
类型T的对象的对象表示形式是类型T的对象所占用的N个无符号字符对象的序列,其中N等于sizeof(T)。类型T的对象的值表示形式是参与表示类型T的值的位集合。对象表示形式中不属于值表示形式的位是填充位。 对于普通可复制类型,值表示形式是对象表示形式中确定值的一组位,该值是实现定义的一组值中的一个离散元素。
为什么突出显示的句子仅限于平凡可复制的类型?是因为不可平凡对象的值表示形式中的某些位可能不在其对象表示形式之外?这个答案,以及这个暗示。
但是,在上面链接的答案中,对象的概念价值基于用户引入的语义。在第一个链接的答案的示例中:
class some_other_type
{
int a;
std::string s;
};
Run Code Online (Sandbox Code Playgroud)
用户确定类型对象的值some_other_type包括属于string的字符s。
我试图考虑一些示例,其中某个对象的值表示(不容易复制)的某些位不在其对象表示之内的事实是隐式的(实现必须这样做,它不是由用户任意确定的)。
我想到的一个例子是,使用虚拟方法的基类子对象的值表示形式可能包含其所属完整对象的对象表示形式中的位,因为基类子对象的行为可能有所不同(可能“具有一个不同的值”),相比之下,它本身就是一个完整的对象。
尽管我想到的另一个例子是,vtable也可能是其vtable指针指向它的对象的值表示的一部分。
这些例子正确吗?还有其他例子吗?
是标准委员会引入突出显示的句子,是因为对象的语义“值”可能由用户决定(如在两个链接的答案中一样),或者由于实现方式可能决定(或可能是强制执行此操作,或两者都执行?
谢谢。
这个问题是关于虚函数调用的(可能的)实现(我相信它被使用gcc)。
考虑以下场景:
f()D 重写B 中声明的虚方法;实例化 F 类型的对象f()D 重写B 中声明的虚方法;实例化 F 类型的对象(这两种场景唯一的区别是B类的继承方式)
在场景 1 中,在对象 B 的 vtable 中,在目标位置处f()现在有一个(非虚拟)thunk 表示:
如果你想调用
f(),首先this用offset
(实际上是D把这个thunk放在那里)
在场景 2 中,在对象 B 的 vtable 中,在指定的位置f()现在有一个(虚拟)thunk 表示:
如果要调用
f(),请首先将this指针更改为存储在的值addr
this(D无法准确告诉B指针需要调整多少,因为它不知道B对象在F对象最终内存布局中的位置)
g++ -fdump-class-hierarchy这些假设是通过结合查看的输出来做出的g++ -S。它们正确吗? …