请考虑以下代码:
class cFoo {
private:
int m1;
char m2;
public:
int doSomething1();
int doSomething2();
int doSomething3();
}
class cBar {
private:
cFoo mFoo;
public:
cFoo getFoo(){ return mFoo; }
}
void some_function_in_the_callstack_hierarchy(cBar aBar) {
int test1 = aBar.getFoo().doSomething1();
int test2 = aBar.getFoo().doSomething2();
...
}
在调用getFoo()的行中,编译器将生成一个cFoo的临时对象,以便能够调用doSomething1()。 编译器是否重用用于这些临时对象的堆栈内存? 调用" some_function_in_the_callstack_hierarchy"会有多少堆栈内存。 reservate?是否为每个生成的临时存储内存?
我的猜测是编译器只为cFoo的一个对象保留内存,并将重用内存用于不同的调用,但如果我添加
int test3 = aBar.getFoo().doSomething3();
我可以看到" some_function_in_the_callstack_hierarchy"所需的堆栈大小。是更多,它不仅仅是因为额外的本地int变量。
另一方面,如果我然后替换
cFoo getFoo(){ return mFoo; }
带引用(仅用于测试目的,因为返回对私有成员的引用不好)
const cFoo& getFoo(){ return mFoo; }
它需要的堆栈内存少于一个cFoo的大小。
所以对我来说,似乎编译器为函数中每个生成的临时对象保留了额外的堆栈内存。但这样效率很低。 有人可以解释一下吗?
答案 0 :(得分:5)
optimizing compiler正在将您的源代码转换为一些内部表示,并对其进行规范化。
使用free software编译器(例如GCC& Clang/LLVM),您可以查看内部表示(至少通过修补编译器代码或在某些代码中运行它调试器)。
BTW,有时候,临时值甚至不需要任何堆栈空间,例如:因为它们已被优化,或者因为它们可以坐在寄存器中。而且他们经常会在当前的调用帧中重用一些不需要的插槽。另外(特别是在C ++中)很多(小)函数都是inlined - 就像你的getFoo
可能是 - (所以他们自己没有任何调用框架)。最近的GCC甚至有时能够tail-call优化(基本上,重用调用者的调用框架)。
如果您使用GCC(即g++
)进行编译,我建议您使用optimization options和developer options(以及其他一些人)。也许使用also -Wstack-usage=48
(或其他一些值,以每个调用帧的字节数为单位)和/或-fstack-usage
首先,如果您可以阅读汇编程序代码,请使用yourcode.cc
编译g++ -S -fverbose-asm -O yourcode.cc
并查看已发出的yourcode.s
(不要忘记使用优化标记,因此请将-O
替换为-O2
或-O3
....)
然后,如果您对编译器的优化方式更加好奇,请尝试g++ -O -fdump-tree-all -c yourcode.cc
,然后您将获得大量所谓的"转储文件"其中包含与GCC相关的内部表示的部分文本呈现。
如果您更加好奇,请查看我的GCC MELT,特别是其documentation页面(其中包含幻灯片和参考的批次)。
所以对我来说,似乎编译器为函数中每个生成的临时对象保留了额外的堆栈内存。
当然不是,在一般情况下(当然假设您启用了一些优化)。即使保留了一些空间,也可以很快重复使用。
BTW:请注意,C ++ 11标准没有提到堆栈。可以想象一些C ++程序在没有使用任何堆栈的情况下编译(例如,整个程序优化检测到没有递归的程序,其堆栈空间和布局可以被优化以避免任何堆栈。我不知道任何这样的编译器,但我知道编译器可以非常聪明....)
答案 1 :(得分:4)
尝试分析 编译器将如何处理特定的代码片段随着优化策略变得更加激进而逐渐变得更加困难。
编译器所要做的就是实现C ++标准并编译代码而不引入或取消任何副作用(有一些例外,例如return和命名返回值优化)。
您可以从代码中看到,由于cFoo
不是多态类型且没有成员数据,编译器可以完全优化对象的创建并调用基本上static
的内容功能直接。我想,即使在我写作的时候,一些编译器已经在做了。您可以随时检查输出组件。
编辑:OP现在已经引入了班级成员。但由于这些从未初始化并且是private
,因此编译器可以删除它们而不必过于考虑。因此,这个答案仍然适用。
答案 2 :(得分:1)
临时对象的生命周期一直持续到完整包含表达式的结尾,请参阅标准的“12.2临时对象”段落。
即使使用最低优化设置,编译器也不太可能在临时对象的生命周期结束后重用该空间。