如果像 C# 和 C# 一样支持的话，您会使用 C++/CLI 吗？ VB.NET？
我一直对 C++/CLI 很感兴趣。 也许是因为没有多少开发人员使用它......或者只是因为它不同。
假设 Microsoft 完全支持 C++/CLI，就像支持 VB.NET 和 C#（即 LINQ、WPF 等）一样。 你会用它吗？
如果没有，为什么？
I've always had a thing for C++/CLI. Maybe because not many developers use it... or just because it's different.
Suppose Microsoft fully supported C++/CLI as they do VB.NET and C# (ie. LINQ, WPF, etc.). Would you use it?
If not, why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我确实使用它。 即使相对缺乏工具支持，它在处理 Win32 方面仍然胜过原始 P/Invoke。
至于 LINQ，我真的不喜欢看到 C++ 语言受到太多的攻击。 LINQ 按原样就足够可用 - 如果他们要增强编译器，他们应该在 C++ 0x 支持上工作......
I do use it. Even with the relative lack of tool support, it still beats raw P/Invoke for dealing with Win32.
As for LINQ, i don't really care to see too much more hacked into the C++ language. LINQ is usable enough as-is - if they're gonna enhance the compiler, they should work on C++ 0x support...
这一切都是为了使用正确的工具完成正确的工作。 我使用 C++/CLI 进行平台互操作工作，因为正确进行编组要容易得多。 我使用 C# 来完成几乎所有其他 .NET 工作，还有一些 VB.Net（我喜欢内联 XML）。 我承认我还没有学习 IronRuby、IronPython、F# 或任何其他 .NET 语言，但我正在认真考虑它只是为了增加我的编程库。
为了回答这个问题，我认为我不会再使用它了，因为我觉得我已经将它用于最适合的工作。 在我看来，C# 仍然是最好的 .NET 语言，因为它是专门为该平台设计的，而不是硬塞一个旧的语言来适应它。 添加对 C++/CLI 更好的支持只会减少我的开发时间，而不会影响我对另一种语言的使用。
It's all about using the right tool for the right job. I use C++/CLI for platform interop work because it's much easier to get the marshaling correct. I use C# for almost all other .NET work, with some VB.Net (I like the inline XML). I admit I haven't learned IronRuby, IronPython, F#, or any other .NET language yet, but I'm seriously considering it just to increase my programming arsenal.
To answer the question, I don't think I'd use it anymore than I already do because I feel I already use it for the jobs it fits best. C# is still the best .NET language as I see it because it was specifically designed for that platform, rather than shoehorning an older language to fit it. Adding better support for C++/CLI would only decrease my development time, rather than sway my usage from another language.
C++/CLI 非常有效地实现了统一托管和非托管代码的承诺。 它可以让您暴露出完美的本机 C# 库，并且可以 100% 访问“内部”本机 C++/库。 这不是一种优雅的练习，但在实用编程工具的历史上有什么可比的呢？
如果您需要 LINQ 和 WPF，只需使用 C#。 这就是 C++/CLI 的美妙之处：编写托管包装器，然后返回到 C#。 我不认为 C++/CLI 打算取代 C# 进行日常使用。
C++/CLI delivers very effectively on the promise of uniting Managed and Unmanaged code. It lets you expose what feels like a perfectly native C# library with 100% access to native C++/libraries "on the inside". It's not an exercise in elegance but in the history of practical programming tools what compares?
If you need LINQ and WPF, just use C#. That's the beauty of C++/CLI: write your Managed wrapper and then go back to C#. I don't see C++/CLI intending to replace C# for day to day use.
一项巨大的好处（在我的书中）是 RAII （请参阅给出的答案作者：Adam Wright 回答我关于.NET 中的 RAII）。
One huge benefit (in my book) is RAII (see the answer given by Adam Wright to my question regarding RAII in .NET).
也许...但我并不完全清楚 C++/CLI 提供了哪些 C# 没有的功能。 也许是指针？ 我已经用 C# 完成了所有 .NET 编程（我所做的很少），并且我开始学习 F#，但如果它得到完全支持并且有良好的文档记录，当然，我会尝试一下。
Perhaps...but I'm not entirely clear on what C++/CLI offers that C# does not. Pointers, perhaps? I've done all of my .NET programming (the little I've done) in C#, and I'm starting to learn F#, but if it was fully supported and well documented, sure, I would give it a go.
我将 C++/CLI 与 MFC 混合以利用 WPF 和 XAML，但我使用新的 C++ 2008 功能包——免费功能区组件。 :)
I am mixing C++/CLI with MFC to take advantage of the WPF and XAML, but I am using the new C++ 2008 feature pack -- free ribbon components. :)
我不会使用它，因为我不想受到巨大的运行时的束缚。 我不喜欢那些 ^ 指针之类的东西 :)
但我确实喜欢/怀念 .NET 提供的优秀库。
I would not use it because I don't want to be tied to a huge run-time. And I don't like all those ^ pointer thingys :)
I do like/miss the great library that .NET offers though.
我用它来支持遗留代码以及在托管代码和本机代码之间编写填充程序。 喜欢 VS11 更好地支持它
I use it to support legacy code as well as writing shims between managed and native code. Love that VS11 supports it much better