为什么调试器的断点条件允许 assignment-statement 作为 bool-condition？
Why does the debugger's breakpoint condition allow an assignment-statement as bool-condition?
这非常危险，所以我想知道为什么允许这样做。因为我经常需要在 VB.NET 和 C# 之间切换，所以我有时会像下面这样添加 breakpoint-conditions：
foo = "bah"
如果 string 变量 foo 是 "bah，我想停止，所以正确的方法是使用 foo == "bah" 而不是 foo = "bah"。
但它"works"。您不会在编译或运行时收到任何警告或错误。但实际上这个 修改了 变量 foo，即使它有不同的值，它也总是 "bah"。由于这种情况是悄无声息地发生的（断点永远不会被击中），因此非常危险。
为什么允许？我的推理错误在哪里（除了混淆 C# 和 VB.NET 语法）？在 C# 中（与 VB.NET 相反）assignment statement returns 分配的值，因此在这种情况下不是 bool，而是 string。但是，如果您选中 "Is True".
框，则断点条件必须是 bool
这是一个小示例 "program" 和我的（德语）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
}
breakpoint-condition 对话框：
包含断点的图片代码：
这是 C# 语法的自动结果，在大括号语言组中很常见。赋值也是一个表达式，它的结果是右边 ope运行d 的值。调试器既不反对具有副作用的表达式，也不会简单地抑制它们。可能会因为没有检查表达式是否具有 bool 结果而受到指责，但是调试器没有成熟的 C# 语言解析器。由于 Roslyn 项目，这可能会在 VS2015 中得到修复。 [注意：见底部的附录]。
这也是花括号语言需要一个单独的相等运算符 == 与 = 的核心原因。这本身就必须对价值十亿美元的错误负责，每个 C 程序员都至少犯过一次这样的错误。
VB.NET不同，赋值是语句，=token对赋值和比较都有效。您可以从调试器中看出，它选择相等运算符而不是修改变量。
请记住，这实际上很有用。它可以让您暂时解决错误，强制变量值并允许您继续调试并专注于另一个问题。或者创造一个测试条件。这很有用。前世写了编译器和调试器，实现了"trace points"。无意中发现了同样的场景，原地不动。它 运行 在严重依赖状态机的主机中，在调试时覆盖状态变量非常有用。意外，不，没那么有用:)
注意其他 SO 用户正在观察的内容，这取决于您使用的调试引擎。 VS2013中的相关选项是Tools + Options, Debugging, General, "Use Managed Compatibility Mode" checkbox。 VS2012 中存在相同的选项，它的名称略有不同（不记得了）。勾选后你会得到一个旧的调试引擎，它仍然与 C++/CLI 兼容。与 VS2010 中使用的相同。
这是 VS2013 的解决方法，取消选中让调试器检查表达式是否产生 bool 结果的选项。您可以使用新的调试引擎获得更多好处，例如查看方法 return 值和 Edit+Continue 对 64 位进程的支持。
我不同意这种行为的错误性质。在我的生活中用于调试目的的几个例子是否有用：
1. 其他线程修改了你的代码。
2. db
中的其他服务更新值
所以我想对于同步的情况它可能是有用的特性，但我同意它会导致问题
在 Visual Studio 2019 年，断点条件中的变量赋值表达式不再起作用。
将计算表达式的值，但丢弃变量赋值等副作用。
这非常危险，所以我想知道为什么允许这样做。因为我经常需要在 VB.NET 和 C# 之间切换，所以我有时会像下面这样添加 breakpoint-conditions：
foo = "bah"
如果 string 变量 foo 是 "bah，我想停止，所以正确的方法是使用 foo == "bah" 而不是 foo = "bah"。
但它"works"。您不会在编译或运行时收到任何警告或错误。但实际上这个 修改了 变量 foo，即使它有不同的值，它也总是 "bah"。由于这种情况是悄无声息地发生的（断点永远不会被击中），因此非常危险。
为什么允许？我的推理错误在哪里（除了混淆 C# 和 VB.NET 语法）？在 C# 中（与 VB.NET 相反）assignment statement returns 分配的值，因此在这种情况下不是 bool，而是 string。但是，如果您选中 "Is True".
bool
这是一个小示例 "program" 和我的（德语）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
}
breakpoint-condition 对话框：
包含断点的图片代码：
这是 C# 语法的自动结果，在大括号语言组中很常见。赋值也是一个表达式，它的结果是右边 ope运行d 的值。调试器既不反对具有副作用的表达式，也不会简单地抑制它们。可能会因为没有检查表达式是否具有 bool 结果而受到指责，但是调试器没有成熟的 C# 语言解析器。由于 Roslyn 项目，这可能会在 VS2015 中得到修复。 [注意：见底部的附录]。
这也是花括号语言需要一个单独的相等运算符 == 与 = 的核心原因。这本身就必须对价值十亿美元的错误负责，每个 C 程序员都至少犯过一次这样的错误。
VB.NET不同，赋值是语句，=token对赋值和比较都有效。您可以从调试器中看出，它选择相等运算符而不是修改变量。
请记住，这实际上很有用。它可以让您暂时解决错误，强制变量值并允许您继续调试并专注于另一个问题。或者创造一个测试条件。这很有用。前世写了编译器和调试器，实现了"trace points"。无意中发现了同样的场景，原地不动。它 运行 在严重依赖状态机的主机中，在调试时覆盖状态变量非常有用。意外，不，没那么有用:)
注意其他 SO 用户正在观察的内容，这取决于您使用的调试引擎。 VS2013中的相关选项是Tools + Options, Debugging, General, "Use Managed Compatibility Mode" checkbox。 VS2012 中存在相同的选项，它的名称略有不同（不记得了）。勾选后你会得到一个旧的调试引擎，它仍然与 C++/CLI 兼容。与 VS2010 中使用的相同。
这是 VS2013 的解决方法，取消选中让调试器检查表达式是否产生 bool 结果的选项。您可以使用新的调试引擎获得更多好处，例如查看方法 return 值和 Edit+Continue 对 64 位进程的支持。
我不同意这种行为的错误性质。在我的生活中用于调试目的的几个例子是否有用：
1. 其他线程修改了你的代码。
2. db
中的其他服务更新值
所以我想对于同步的情况它可能是有用的特性，但我同意它会导致问题
在 Visual Studio 2019 年，断点条件中的变量赋值表达式不再起作用。
将计算表达式的值，但丢弃变量赋值等副作用。