(如何)调试更改程序的工作流程? [英] (How) does debugging change the workflow of the program?

查看:130
本文介绍了(如何)调试更改程序的工作流程?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

考虑以下简单的程序:

  var dblMax = Double.MaxValue; 

var result =(dblMax * 1000)/ 1800;
Console.WriteLine(result);当我在Debug模式下构建它并运行(Ctrl + F5)或调试(F5)时,



<它打印 9.987140856842E + 307



当我切换到发布模式并运行(Ctrl + F5)它打印 8 为无穷大。



我明白这种差异是由于一些编译器优化在Release



但是,如果我在发布模式下调试(F5)相同的构建,则打印 9.987140856842E + 307 再次!



我正在调试的事实如何改变计算结果?



编辑:



我不问为什么调试模式和释放模式产生不同的结果。我不知道为什么释放模式会产生不同的结果,这取决于我是否调试(F5)还是不调试(Ctrl + F5)。

解决方案

调试时JITter的行为是不同的。



一方面,局部变量在许多情况下会改变其生命周期以便检查。考虑在计算过程中使用变量后点击一个断点。如果JITter知道变量在表达式之后不会被使用,并且没有延长变量的生命周期,那么你可能最终不能看这个变量,这是调试的核心特征。 / p>

JITer有一个非常清楚的知识,当一个变量有用的时候还有一些谎言。如果在这段时间内有一个注册表可用,最终可能会使用该寄存器来存储变量。



但是,调试器附加它可能会决定使用内存位置,因为生命周期变化足够,以致寄存器不可用于该部分代码。



CPU的浮点寄存器的精度高于相应的浮点数存储格式,这意味着一旦您将一个值从寄存器中提取到内存中,或者将其全部存储在内存中,您的精度将会降低。



RELEASE和DEBUG构建之间的区别可能会导致这些事情的发生,以及调试器的存在。



另外,不同的.NET运行时间之间可能存在差异可能影响这一点的版本。






正确编写浮点代码需要对您正在尝试做什么的深入了解d机器和平台的各个部分如何干扰。我会尽量避免编写这样的代码。


Consider the following simple program:

var dblMax = Double.MaxValue;

var result = (dblMax * 1000) / 1800;
Console.WriteLine(result);

When I build this in Debug mode and run (Ctrl+F5) or debug (F5) it, it prints 9.987140856842E+307.

When I switch to Release mode and run (Ctrl+F5) it, it prints 8 for infinity.

I understand that this difference is due to some compiler optimization which is done in Release mode.

However, if I debug (F5) the same build in Release mode, it prints 9.987140856842E+307 again!

How does the fact that I am debugging change the result of the calculation?

Edit:

I do not ask why debug mode and release mode yield different results. I wonder why release mode is yielding different results depending on whether I debug (F5) or not (Ctrl+F5).

解决方案

When debugging the JITter behaves different.

For one thing, local variables will in many cases have their lifetimes changed in order to be inspectable. Consider hitting a breakpoint after a variable was used during a calculation. If the JITter knows the variable is not going to be used after the expression, and it didn't prolong the lifetime of the variable, you could end up not being able to look at that variable, which is a core feature of debugging.

The JITer has a very clear knowledge about when a variable is useful to still have lying around. If during that time a register is available it might end up using this register to store the variable in.

However, with the debugger attached it might decide to instead use a memory location because the lifetime changed enough so that a register isn't available for that part of the code.

Floating point registers of the CPU have higher precision than the corresponding floating point storage formats, which means that once you either lift a value out of a register and into memory, or simply store it in memory the whole time, you will experience lower precision.

The difference between RELEASE and DEBUG build can end up dictating these things, as can the presence of a debugger.

Additionally, there can be differences between the different .NET runtime versions which can affect this.


Writing floating point code correctly requires intimate knowledge about what you are attempting to do and how the various parts of the machine and platform will interfere. I would try to avoid writing code like this.

这篇关于(如何)调试更改程序的工作流程?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆