Question

好吧，我发现这对我来说非常奇怪，但在C＃中，你实际上可以用不同的语言编写源代码。我用韩语写了一个示例源代码来说明我的观点：

namespace 대한민국 {
    public class 학생 {
        public string 이름 { get; private set; }
        public string 좌우명 { get; private set; }

        public 학생(string 이름, string 좌우명) {
            this.이름 = 이름;
            this.좌우명 = 좌우명;
        }
    }
    public class 대학교 {
        private List<학생> 재학생목록 = new List<학생>();

        public void 입학(학생 입학생) {
            재학생목록.Add(입학생);
        }

        public void 재학생출력() {
            foreach (학생 선택된학생 in 재학생목록) {
                Console.WriteLine("이름: {0}", 선택된학생.이름);
                Console.WriteLine("좌우명: {0}", 선택된학생.좌우명);
            }
        }
    }
    public class 프로그램 {
        static void Main(string[] args) {
            대학교 스쿨오브헬 = new 대학교();
            스쿨오브헬.입학(new 학생("전땅끄", "본인은 단돈 29만원과 땅끄로 이 신성하고 거룩한 국가의 민주주의를 발전시켰소"));
            스쿨오브헬.입학(new 학생("이피카츄", "여러분 이거 다 거짓말인거 아시죠!!!"));
            스쿨오브헬.입학(new 학생("빵상아줌마", "빵빵 똥똥똥똥 땅땅 따라라라라~~~"));

            스쿨오브헬.재학생출력();
        }
    }
}

上面的代码编译并为您提供有效的输出。

除关键字外，您实际上可以使用英语以外的语言编写源代码。当然，这是非常不切实际的，没有人会这样做。

我的问题如下：

这是C＃功能还是Visual Studio功能？（我无法在Visual Studio 2010下使用C ++开发类似的程序）
对性能有何影响？（我很乐意假设几乎没有，但不确定他们是否进行了任何类型的疯狂转换以允许非ASCII字符进行编码）
实施此功能的原因是什么？

Answer 1

1：它是C＃语言规范，所以：C＃

2：无论如何;解析器并不关心某些东西是Fred vs 프로그램;对编译器来说都不重要

3：因为并非所有开发人员都会说英语（或拉丁语言）作为他们的主要语言。很可能프로그램对于从事该项目的开发人员非常容易和有意义地表达了该类的意图

Answer 2

1）C＃规范和CLI规范都允许这样做。

C＃标准说

源文件是Unicode字符的有序序列。

和

符合规定的程序中的标识符必须采用规范格式由Unicode规范化表格C定义，由Unicode定义标准附件15.遇到不在的标识符时的行为规范化表格C是实现定义的;但是，诊断不是必需的。

ECMA CLI标准可以这样说：

I.8.5命名

为系统类型的实体提供名称，以便其他人可以引用它们   系统类型的部分或类型的实现。类型，领域，方法，   属性和事件都有名称。关于类型系统，价值观，本地人和   参数没有名称。类型系统的实体被赋予单个名称（例如，   一种类型只有一个名称）。

I.8.5.1有效名称

所有名称比较都是逐字节完成的（即区分大小写，区域设置 -   独立的，也称为代码点比较）的基础。名称用于访问的位置   内置VES提供的功能（例如，类初始化方法）   始终是定义的附带说明，以便不构建任何一组   保留名称。

重要段落如下：

CLS规则4：大会应遵循Unicode技术报告15的附件7   标准3.0管理允许启动和包含的字符集   标识符，可在http://www.unicode.org/unicode/reports/tr15/tr15-18.html在线获取   标识符应采用Unicode规范化表C定义的规范格式。   对于CLS目的，如果它们的小写映射（如指定的话），则两个标识符相同   通过Unicode区域设置不敏感，一对一的小写映射）是相同的。那是，   对于在CLS下被认为是不同的两个标识符，它们应该有更多不同   不仅仅是他们的情况。但是，为了覆盖CLI的继承定义   要求使用原始声明的精确编码。

[注：   CLS（消费者）：不需要消费违反CLS规则4的类型，但应具有   允许访问使用其自己的关键字之一作为名称的命名项的机制。   CLS（扩展器）：无需创建违反CLS规则4的类型。应提供一种机制   用于定义遵守这些规则的新名称，但与...中的关键字相同   语言。   CLS（框架）：不得导出违反CLS规则4的类型。应避免使用   通常在编程语言中用作关键字的名称。

2）不应对性能产生任何影响。 CLI规则规定必须使用Unicode区域设置不敏感映射来完成名称匹配，这意味着当需要比较两个名称时，必须转换为Unicode代码点序列。如果，编译器或运行时选择将此信息保存在可变长度编码（如UTF-8）中并在运行时转换为代码点，那么理论上会有一些性能差异;实际上我不希望任何实现这样做，或者如果他们这样做，性能差异是可测量的。

请注意，CLS规则4表示“为了覆盖继承的定义，CLI需要使用原始声明的精确编码”，这在覆盖名称时会产生特定的限制。但由于这不是一项普遍的要求，因此无论如何都必须实现“在比较之前将所有内容转换为代码点”。

3）同样，它在CLI规范中，因此语言必须这样做。

以非ASCII语言编码

2 个答案:

I.8.5命名

I.8.5.1有效名称