Vb.net 为什么Chr（3）是常数表达式而不是Chr（172）？

如果我编写以下代码，ReSharper将建议我将第一个变量

chr3

转换为常量，但不将第二个变量

chr127

转换为常量

公共类ClassX
公共子方法（）
尺寸chr3作为字符串=Chr（3）
尺寸chr172作为字符串=Chr（172）
Debug.WriteLine（chr3）
Debug.WriteLine（chr172）
端接头
末级

如果我将两者都转换为常量，则会在

Chr（172）

上收到一条Visual Studio编译器警告，指出“常量表达式是必需的””，但

Chr（3）

没有编译器警告

公共类ClassX
公共子方法（）
常量chr3作为字符串=Chr（3）
常量chr172作为字符串=Chr（172）
Debug.WriteLine（chr3）
Debug.WriteLine（chr172）
端接头
末级

---

是什么使

Chr（3）

成为一个常量表达式而不是

Chr（172）

？

字符3是“文本结尾”字符，因此它可能表现出奇怪的行为似乎并不奇怪。此字符和其他类似字符很少直接使用。

查看Microsoft.VisualBasic.Strings.Chr（）的源代码，我看到了以下内容（我在本文中通过删除异常处理简化了这些内容）：

//
///返回与指定字符代码关联的字符。
/// 
/// 
/// 
///返回与指定字符代码关联的字符。
/// 
///必需的。表示字符的代码点或字符代码的整数表达式。对于Chr.1，为0或255
公共静态字符Chr（int CharCode）
{
如果（CharCode=0&&CharCode>8））；
字节[1]=已检查（（字节）（CharCode和（int）byte.MaxValue））；
chars2=解码器.GetChars（字节，0，2，chars1，0）；
}
返回字符1[0]；
}

似乎对于7位值，

Convert.ToChar（CharCode）

返回，我猜编译器足够聪明，可以得出结论，这是一个常量，而对于8位值，当前区域性的代码页会涉及，这将根据代码运行的计算机给出不同的结果，因此不可能是常数

更新：我曾尝试在自己编写的方法中复制这种情况，但不能，这表明编译器本身可能有一个计算常量表达式的特殊案例规则

专用函数consornot（输入为Int32）为Int32
如果输入=3，则返回7
返回（新随机）。下一步
端函数
常数intC1为Int32=常数（3）

---

（也就是说，

consornot（）

与调用它的代码存在于同一个程序集中，因此这可能根本不起作用。）

+1个有趣的问题。我很确定这与172在标准ASCII表之外有关（它是7位的，我希望你的问题会出现在127以上的值上），但是我不知道为什么它会这样困扰编译器。很好的洞察力。它似乎确实与8位值有关，因为122和127的样本值被接受为常量表达式，但128和172不是