编译器如何确定具有编译器生成的临时函数的函数所需的堆栈大小？

Question

考虑以下代码：

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”的调用将保留多少堆栈内存？ 是否为每个生成的临时存储内存？

我的猜测是编译器只为cFoo的一个对象保留内存，并将重用内存用于不同的调用，但如果我添加

    int test3 = aBar.getFoo().doSomething3();

我可以看到“some_function_in_the_callstack_hierarchy”所需的堆栈大小更多，而且不仅仅是因为附加的本地int变量。

另一方面，如果我然后更换

cFoo getFoo(){ return mFoo; }

带引用（仅用于测试目的，因为返回对私有成员的引用不好）

const cFoo& getFoo(){ return mFoo; }

它需要的堆栈内存少于一个cFo​​o的大小。

所以对我来说，似乎编译器为函数中的每个生成的临时对象保留了额外的堆栈内存。 但这样效率很低。 有人可以解释一下吗？

Answer 1

优化编译器正在将您的源代码转换为一些内部表示，并对其进行规范化。

使用免费软件编译器（如GCC和Clang / LLVM ），您可以查看内部表示（至少通过修补编译器代码或在某些调试器中运行它）。

BTW，有时候，临时值甚至不需要任何堆栈空间，例如因为它们已被优化，或者因为它们可以位于寄存器中。 而且他们经常会在当前的调用帧中重用一些不需要的插槽。 另外（特别是在C ++中）很多（小）函数都是内联的 - getFoo你的getFoo可能是 - （所以他们自己没有任何调用框架）。 最近的GCC甚至有时能够进行尾调用优化（实质上是重用调用者的调用帧）。

如果您使用GCC（即g++ ）进行编译，我建议您使用优化选项和开发人员选项 （以及其他一些选项 ）。 也许也使用-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 ，特别是其文档页面（其中包含大量幻灯片和参考文献）。

所以对我来说，似乎编译器为函数中的每个生成的临时对象保留了额外的堆栈内存。

当然不是，在一般情况下（当然假设你启用了一些优化）。 即使保留了一些空间，也可以很快地重复使用。

^{顺便说一句：请注意，C ++ 11标准没有提到堆栈。 可以想象一些C ++程序在没有使用任何堆栈的情况下编译（例如，整个程序优化检测到没有递归的程序，其堆栈空间和布局可以优化以避免任何堆栈。我不知道任何这样的编译器，但我知道编译器可以很聪明....）}

Answer 2

随着优化策略变得更加激进，尝试分析编译器如何处理特定代码片段变得越来越困难。

编译器所要做的就是实现C ++标准并编译代码而不引入或取消任何副作用（有一些例外，例如返回和命名返回值优化）。

您可以从代码中看到，由于cFoo不是多态类型且没有成员数据，因此编译器可以完全优化对象的创建，并直接调用基本上是static函数的东西。 我想，即使在我写作的时候，一些编译器已经在做了。 您可以随时检查输出组件。

编辑：OP现在已经引入了类成员。 但由于这些从未初始化并且是private ，因此编译器可以删除它们而不必过于考虑。 因此，这个答案仍然适用。

Answer 3

临时对象的生命周期一直持续到完整包含表达式的结尾 ，请参阅标准的“12.2临时对象”段落。

即使使用最低优化设置，编译器也不太可能在临时对象的生命周期结束后重用该空间。