移植C++ 难吗？到 C++/CLI？
我想您不能简单地使用 C++/CLI 编译器编译 C++ 应用程序。我想知道会不会很难。有人尝试过吗？如果是的话：是否需要进行大量修改？
I suppose you cannot simply compile a C++ application with a C++/CLI compiler. I am wondering if it would be difficult. Has anybody tried this, and if so: were there a lot of modifications needed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这种情况有点像将 C 编译为 C++。大多数 C 都会编译为 C++，但与您所认为的示例性 C++ 相去甚远，因此您很可能在使用它之前想要对其进行修改（通常是相当多的修改）。
同样，大多数 C++ 将编译为 C++/CLI，但您可能不想真正以这种方式使用它。
The situation is a bit like compiling C as C++. Most C will compile as C++, but is a long ways from what you'd think of as exemplary C++, so chances are that you'd want to modify it (often quite a bit) before you used it.
Likewise, most C++ will compile as C++/CLI, but chances are that you'd rather not really use it that way.
这对于几乎所有本机 C++ 代码都适用。它将被翻译为 IL，就像托管代码一样，并在运行时进行 JIT 编译。借助 C++ 互操作，您可以自由调用托管代码。我知道唯一无法编译的非托管代码构造是 __fastcall 关键字。 const 关键字有一个问题，它不能完美地模拟属性，但这只是导入元数据时的问题。像现在一样继续使用头文件即可。
.NET 程序集能够存储机器代码和 IL。在编译器出现问题或怀疑生成的代码不是最佳的情况下，您可以通过有选择地关闭 IL 生成来利用这一点。使用 #pragma 包装代码：
当您 #include 未使用 /clr 编译选项单独编译的 .lib 标头时，您还需要使用此 #pragma。
This will work well for almost any native C++ code. It will get translated to IL, just like managed code, and get JIT compiled at runtime. You can freely call managed code, thanks to C++ interop. The only unmanaged code construct I know that can't be compiled is the __fastcall keyword. There's an issue with the const keyword, it is imperfectly simulated with attributes, but that's only an issue when you import metadata. Just keep using header files like you do now.
A .NET assembly is capable of storing machine code as well as IL. You can take advantage of this by selectively turning off IL generation for cases where the compiler has trouble or when you suspect generated code isn't optimal. Wrap your code with a #pragma:
You will also need to use this #pragma when you #include headers for .libs that were compiled separately without the /clr compile option.