Question

我知道在发布版本中单步执行代码会导致指示当前代码执行点的箭头跳过某些（至少表面上）奇怪且误导性的地方。我的问题是：是否有任何可预测和可理解的内容可供人们阅读，哪些可能有助于解决仅在发布版本中发生的问题，而不是在调试版本中？

具体示例我正试图找到底部:(在调试中工作，而不是在发布中）

void Function1( void )
{
  if ( someGlobalCondition )
    Function2( 10 );
  else
    Function2();
}

void Function2( const int parameter = 1 )    // see note below
{
  DoTheActualWork();    // any code at all
}

// and finally lets call Function1() from somewhere...
Function1();

注意：为简洁起见，我省略了这两个函数都在头文件中声明，并在.cpp文件中单独实现的事实。因此，Function2()中的默认参数表示法对它有一些自由。

好的 - 所以在Debug中，这很好用。在Release中，即使明确依赖someGlobalCondition，代码指针仍会完全跳过Function1()的主体并直接执行Function2()，但始终使用默认参数（并且永远不会10）。这有点表明Function1()正在编译时被优化掉......但是有没有任何依据可以得出这样的结论？有没有办法确定发布版本是否实际检查过someGlobalCondition？

P.S。（1）这不是XY问题。我给出了Y的上下文，所以我可以让问题X变得更有意义。（2）不，我不会发布我的实际代码，因为那会强调Y问题，除了我以外，对任何人都有极低的价值，而X问题是多年来一直困扰我（可能还有其他人）的问题。 p>

Answer 1

好吧，在没有实际代码的情况下，我们可以推测的是编译器正在确定someGlobalCondition永远不会是真的。

这是唯一可以正确优化Function1并始终使用Function2参数直接调用1的情况。

如果您希望某些正在进行此优化，那么最好的办法是分析编译器生成的汇编代码或机器代码。

Answer 2

而不是寻求文档来解释明显无法解释的问题，而是在单步执行时切换到反汇编视图。您将了解编译器如何优化代码以及它如何考虑所有内容......因为将考虑到所有内容。

如果您没有看到条件运行时测试的证据（例如jne或test或cmp等），那么您可以安全地假设编译器已确定您的条件（s ）要保持不变，你可以调查它为什么。如果您看到有关条件的证据，但从未得到满足，那么这将指向另一个方向。

此外，如果您认为优化的好处不会超过难以理解的代码执行点行为的成本，那么您可以随时关闭优化。

Visual Studio C ++在发布版本中单步执行代码

2 个答案: