为什么调试器的断点条件允许赋值语句布尔条件？ [英] Why does the debugger's breakpoint condition allow an assignment-statement as bool-condition?

问题描述

所以我不知道为什么它是允许的，这是非常危险的。由于我经常需要VB.NET和C＃之间切换有时我加断点条件类似以下内容：

This is very dangerous so I wonder why it's allowed. Since I often need to switch between VB.NET and C# I sometimes add breakpoint-conditions like following:

foo = "bah"

我想停下来，如果字符串变量富是呸，所以正确的方法是使用富==呸 而不是富=呸。

I want to stop if the string variable foo is "bah, so the correct way was to use foo == "bah" instead of foo = "bah".

但它作品你在之前编制或运行时没有得到任何警告或错误。但实际上这的修改的变量富，它使得它总是呸即使它有不同的价值。因为这种情况提示（断点从来没有被击中），这是令人难以置信的危险。

But it "works". You don't get any warnings or errors at compile- or runtime. But actually this modifies the variable foo, it makes it always "bah" even if it had a different value. Since that happens silently (the breakpoint never gets hit) it is incredibly dangerous.

为什么允许它在哪里？我的推理（除了混淆了C＃和VB.NET语法）？在C＃中（而不是VB.NET）错误的的赋值语句返回分配的价值，所以不是布尔，但在这种情况下，字符串。但是断点条件必须是布尔如果您勾选的为真的

Why is it allowed? Where is my error in reasoning (apart from confusing the C# and VB.NET syntax)? In C# (as opposed to VB.NET) an assignment statement returns the value that was assigned, so not a bool, but a string in this case. But a breakpoint condition has to be a bool if you check the box "Is True".

下面是从我（德国）IDE一个小样本方案和截图：

Here is a little sample "program" and screenshots from my (german) IDE:

static void Main()
{
    string foo = "foo";
    // breakpoint with assignment(foo = "bah") instead of comparison(foo == "bah"):
    Console.WriteLine(foo);  // bah, variable is changed from the breakpoint window
}

断点条件对话框

The breakpoint-condition dialog:

中的代码为图像，包括断点：

The code as image including the breakpoint:

推荐答案

这是C＃语法的必然结果，常见于在大括号语言组。一个分配也是一种表达，其结果是右手侧的操作数的值。调试器不反对要么有副作用的表达，也不是简单的在所有镇压他们。它可以被指责为不检查表达式具有的布尔的结果，但调试器不具有全面的C＃语言解析器。这很可能固定在VS2015感谢罗斯林项目。 [注：见底部补遗。

It is an automatic consequence of C# syntax, common in the curly-braces language group. An assignment is also an expression, its result is the value of the right-hand side operand. The debugger does not object either to expressions having side-effects, nor would it be simple at all to suppress them. It could be blamed for not checking that the expression has a bool result, the debugger however does not have a full-blown C# language parser. This might well be fixed in VS2015 thanks to the Roslyn project. [Note: see addendum at the bottom].

另外，核心原因是，花括号语言需要平等的独立运营商，== VS =。这本身就必须是负责十亿美元身价的bug，每一个C程序员，使这个错误至少一次。

Also the core reason that the curly-brace languages need a separate operator for equality, == vs =. Which in itself must be responsible for a billion dollar worth of bugs, every C programmer makes that mistake at least once.

VB.NET是不同的，分配是一个声明，在 = 标记都有效分配和比较。您可以从调试器来讲，它采平等操盘，并且不修改变量。

VB.NET is different, assignment is a statement and the = token is valid for both assignment and comparison. You can tell from the debugger, it picks the equality operator instead and doesn't modify the variable.

请记住，这是真正有用的。它可以让你暂时解决错误，迫使该变量的值，并允许您继续调试，并专注于另一个问题。或创建一个测试条件。这是非常有用的。在以前的生活时，我写了一个编译器和调试并实施跟踪点。意外发现了相同的情况下，离开到位。它跑在很大程度上依赖于状态机，覆盖状态变量在调试时是非常有用的主机。事故发生后，没有，没有那么有用：）

Do keep in mind that this is actually useful. It lets you temporarily work around a bug, forcing the variable value and allowing you to continue debugging and focus on another problem. Or create a test condition. That's pretty useful. In a previous life-time, I wrote a compiler and debugger and implemented "trace points". Discovered the same scenario by accident and left it in place. It ran in a host that relied heavily on state machines, overriding the state variable while debugging was incredibly useful. The accident, no, not so useful :)

什么其他让网友们观察笔记，这取决于您使用调试引擎。在VS2013相关选项，工具+选项，调试，通用，使用管理兼容模式复选框。同样的选项存在于VS2012，它有一个稍微不同的名称（不记得了）。当打勾你得到一个较旧的调试引擎，一个是仍与C ++ / CLI兼容。在VS2010中使用同一个。

A note about what other SO users are observing, it depends on the debugging engine that you use. The relevant option in VS2013 is Tools + Options, Debugging, General, "Use Managed Compatibility Mode" checkbox. Same option exists in VS2012, it had a slightly different name (don't remember). When ticked you get an older debugging engine, one that is still compatible with C++/CLI. Same one as used in VS2010.

所以这是对VS2013一种变通方法，取消勾选拿到调试器来检查表达式产生一个布尔结果的选项。你得到一些更多的好东西与新的调试引擎，就像看到方法的返回值和编辑+继续对64位程序提供支持。

So that's a workaround for VS2013, untick the option to get the debugger to check that the expression produces a bool result. You get some more goodies with that new debugging engine, like seeing method return values and Edit+Continue support for 64-bit processes.

这篇关于为什么调试器的断点条件允许赋值语句布尔条件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！