C# 空合并 (??) 运算符的运算符优先级是什么？
我刚刚尝试了以下操作，其想法是连接两个字符串，用空字符串替换空值。
string a="Hello";
string b=" World";
-- 调试（有趣的是？是打印，并不完全有助于可读性......）
? a ?? "" + b ?? ""
-> “Hello”
正确的是：
? (a??"")+(b??"")
"Hello World"
我有点期待“Hello World”，或者如果 a 为空，则只是“World”。 显然，这与运算符优先级有关，可以通过括号来克服，是否有任何地方记录了这个新运算符的优先级顺序。
（意识到我可能应该使用 stringbuilder 或 String.Concat）
谢谢。
I've just tried the following, the idea being to concatenate the two strings, substituting an empty string for nulls.
string a="Hello";
string b=" World";
-- Debug (amusing that ? is print, doesn't exactly help readability...)
? a ?? "" + b ?? ""
-> "Hello"
Correct is:
? (a??"")+(b??"")
"Hello World"
I was kind of expecting "Hello World", or just "World" if a is null. Obviously this is todo with operator precedence and can be overcome by brackets, is there anywhere that documents the order of precedence for this new operator.
(Realising that I should probably be using stringbuilder or String.Concat)
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
除了您想要的优先级、ECMA 的规定、MS 规范的规定以及 csc 的实际用途之外，我还有一点建议：
不要这样做。
我认为写起来更清楚：
或者，考虑到字符串连接中的 null 最终只是一个空字符串，只需写：
编辑：关于记录的优先级，在 C# 3.0 规范 ( Word 文档）和 ECMA-334，另外比 ?? 绑定更紧密，而 ?? 比赋值绑定更紧密。 另一个答案中给出的 MSDN 链接是错误且奇怪的，IMO。 2008 年 7 月的页面上显示了一项更改，其中移动了条件运算符 - 但显然是错误的！
Aside from what you'd like the precedence to be, what it is according to ECMA, what it is according to the MS spec and what csc actually does, I have one bit of advice:
Don't do this.
I think it's much clearer to write:
Alternatively, given that null in string concatenation ends up just being an empty string anyway, just write:
EDIT: Regarding the documented precedence, in both the C# 3.0 spec (Word document) and ECMA-334, addition binds tighter than ??, which binds tighter than assignment. The MSDN link given in another answer is just wrong and bizarre, IMO. There's a change shown on the page made in July 2008 which moved the conditional operator - but apparently incorrectly!
切勿依赖运算符优先级。 始终明确指定您希望代码如何运行。 当您回到代码时，请为自己和他人一个忙。
这没有留下任何歧义的余地。 歧义是错误的滋生地。
Never rely on operator precedence. Always explicitly specify how you want your code to act. Do yourself and others a favour for when you come back to your code.
This leaves no room for ambiguity. Ambiguity is the breeding ground of bugs.
运算符优先级记录在 MSDN 上。
但是，MSDN 上的优先级与 可下载的 C# 规范 也来自 Microsoft，以及 ECMA 规范。 这有点奇怪。
无论如何，正如 Jon Skeet 在他的回应中所说，最好不要依赖运算符的优先级，而是通过使用括号来明确。
The operator precedence is documented on MSDN.
However the precedence on MSDN contradicts the precedence in both the downloadable C# spec also from Microsoft, and the spec on ECMA. Which is a little odd.
Irrespective, as Jon Skeet said in his response, best not to rely on precedence of operators, but to be explicit through use of brackets.
有趣的是 http://msdn.microsoft.com/en-us/library /6a71f45d.aspx 和 http://en.csharp- online.net/ECMA-334:_14.2.1_Operator_precedence_and_associativity 为 ?? 提供不同的优先级。
msdn：
ECMA：
msdn一定是错误的，考虑：
It interesting that http://msdn.microsoft.com/en-us/library/6a71f45d.aspx and http://en.csharp-online.net/ECMA-334:_14.2.1_Operator_precedence_and_associativity give different precedence to ??.
msdn:
ECMA:
I think the msdn must be wrong, consider: