C＃到C ++ / CLI转换的陷阱

Question

我被要求将一些C＃代码转换为C ++ / CLI。 我的一位经理询问了两者之间翻译概念的潜在陷阱。

我很清楚这两种语言都被编译成通用接口语言，并在相同的通用语言运行时中运行。 但是，可以保证为.NET Framework 4.5编译并调用File.Exists（someFile）;的一段C＃代码。 将以与为.NET Framework 4.5编译并调用File :: Exists（someFile）的C ++ / CLI代码完全相同的方式编译为CIL。 ？

从理论上讲，答案是肯定的，因为这似乎是.NET框架的基础。 但是，有没有一种方法可以验证这一点？ 是否出于某种技术原因必须/不可能如此？

Answer 1

编写C ++ / CLI代码时肯定会有一些陷阱，并且您对C＃非常了解，但对C ++ / CLI却不了解。 我将避免把它变成一个列表问题，并列举所有这些，只是更常见的错误：

• C ++ / CLI要求您具体说明值类型和引用类型之间的区别的语言语法。 您必须在引用类型引用上使用hat ^。 像String^ foo; 。 但是有时您没有，则有意忽略了它。 像StreamReader file;一样StreamReader file; 。 启用“堆栈语义”，这是C ++ RAII模式的仿真。 换句话说，当超出范围时，编译器将自动处理文件变量。 您可以从C＃ using语句知道这一点。 最大的陷阱是当您不应该使用帽子时，例如int^ x = 42; 。 编译器会毫无保留地接受它，但是最终会得到一个装箱的int，这在运行时效率极低。

• C ++ / CLI语言和工具集的开发于2005年停止，此后一直处于维护模式。 因此，它没有获得C＃在那个时间范围内获得的好处，Linq当然是最重要的补充。 没有lambda表达式支持，没有匿名类型，没有扩展方法。 您将不会喜欢转换使用这些语法结构的C＃代码。

• 只有不断的原因之一考虑C＃转换为C ++ / CLI，它是采取的与非托管代码互操作的大力支持优势。 无需纠结pinvoke。 一个非常常见的错误是将所有内容编译为MSIL，包括本机C ++代码。 效果很好，C ++ / CLI编译器能够将任何C ++编译为IL，只要它是符合C ++ 03的标准代码即可。 但是结果是效率低下的 ，它肯定不会在运行时作为托管代码运行，并且像正常情况一样抖动，但是没有本机代码生成器的好处。 哪个可以更好地优化代码。

• 编译器的输出是普通的MSIL，与C＃生成的完全相同。 加上使用C ++的程序各部分的本地代码，从而生成混合模式的程序集。 这使程序集依赖于过程的细节。 换句话说，您可能从C＃项目中知道的AnyCPU目标不适用。 这是您在EXE项目中需要注意的事项，必须明确了解Platform目标设置。 使用“ x86”是确保您的程序在64位操作系统上运行时仍能正常工作的常用选择。 如果要在64位OS上将程序作为64位进程运行，则需要创建两个 C ++ / CLI程序集版本，并使用安装程序部署正确的程序集。

您不必担心File :: Exists（somefile）调用，在MSIL中只有一种方法可以调用该方法。 C ++ / CLI编译器将生成与C＃编译器完全相同的IL。 如果您真的很担心，那么可以使用ildasm.exe这样的反编译器查看IL，从而建立信心。

Answer 2

[C]确保已为.NET Framework 4.5编译并调用File.Exists(someFile);的一段C＃代码File.Exists(someFile); 将以与为.NET Framework 4.5编译并调用File::Exists(someFile);的C ++ / CLI代码完全相同的方式编译为CIL File::Exists(someFile); ？

不，不能保证。

实际上， 甚至不能保证通过C＃编译器运行两次相同的源代码会产生相同的二进制输出 。 因此，可以肯定，两种不同语言的两种不同编译器可能会生成不同的代码。

（请记住， 可能 ，实际上可能经常这样做 。但是我们在这里谈论担保 。）

我不明白的是为什么这可能很重要。 由于调用了相同的方法，因此代码将执行相同的操作。 不仅由文档保证，而且还可以通过反汇编.NET Framework DLL进行自我验证。

不能保证两个程序都具有相同的二进制文件。 一旦通过JIT编译器，就不会有任何反应。 这就是重点。