请描述一下您使用 Microsoft C++/CLI 的体验
C++/CLI 是非常强大的语言。 它是唯一可以无缝组合托管和非托管代码的 CLR 语言。 有多少软件开发人员（在本网站上）正在使用这种语言？ 您在什么类型的项目中使用它？ 是对遗留代码的改编还是原始软件的创建？ 您能将旧的托管 C++ 与新的 C++/CLI 进行比较吗？ 您对 C++/CLI 当前的质量和未来有何看法？
C++/CLI is very powerful language. It's the only CLR language where you can seamlessly combine managed and unmanaged code. How many software developers (on this site) are using this language? In what kind of projects do you use it? Is it an adapting of legacy code or creation of an original software? Can you compare old Managed C++ with new C++/CLI? What do you think about the current quality and about the future of C++/CLI?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我用它来编写托管代码和本机代码之间的薄层集成。 仅此而已。
它最著名的独特功能是能够无缝地深入研究非托管代码并在整个过程中修改（或意外损坏）任何可写内存——这在一般编程中不是一个优势，但当你需要它时，它就很棒了。 但我想我会越来越不需要它。 您可以使用 /pure 标志编译 C++/CLI，但随后它就真正成为一种全新的语言。
不过，还有另外两个重要的独特功能：
析构函数可以做一些有用的事情。 在 C# 中，析构函数是终结器。 在 C++ 中，它是一个适当的确定性调用的析构函数。 这意味着 C++/CLI 拥有最完整的 IDisposable 基础架构。 C# 仅帮助客户端（通过 using 语句），但只有 C++/CLI 也可以帮助实现者。 我希望有一天 C# 能够吸收这一功能。
鸭子类型模板，可以与 CLI 泛型一起使用。 另一个在 C# 中非常有用的东西，尽管它可以在没有历史包袱的情况下变得更加无缝。
但 C# 已经足够好了，没有最后两件事，我一般不会想使用 C++/CLI。
I've used it to write thin layers of integration between managed and native code. That's all though.
The best known unique feature of it is the ability to seamlessly delve into unmanaged code and modify (or accidentally corrupt) any bit of writeable memory in the entire process - that's not an advantage in general programming, but when you need it, it's great. But I think I'm going to need it less and less. You can compile C++/CLI with a /pure flag, but then it really becomes a completely new language.
There are two other big unique features though:
Destructors that do something useful. In C# a destructor is a finalizer. In C++ it is a proper deterministically-called destructor. This means that C++/CLI has the most complete infrastructure for working with
IDisposable. C# only helps clients (through the using statement), but only C++/CLI helps implementors as well. I'm hopeful that perhaps one day C# will absorb this feature.Duck-typing templates, which can be used along with CLI generics. Another thing that would be very useful in C#, although it could be made a lot more seamlessly without the historical baggage.
But C# is good enough without the last two things that I'm not tempted to use C++/CLI generally.
我使用 C++/CLI 进行模拟项目。 我执行实际计算的模拟引擎是用 C++ 编写的现有代码库。 我需要一个 GUI 前端，我成功地用 C++/CLI 对其进行了编码。
在我看来，该语言与 C# 一样易于编写代码，尽管在语法上略有尴尬。 也就是说，语法比 Microsoft 之前提出的托管扩展要简单得多。
C++/CLI 最强大的功能之一就是能够简单地将现有的本机 C++ 代码重新编译为 MSIL。 当然，可能会出现一些问题，但对于大多数应用程序来说，这应该是一个没有问题的练习。
至于 C++/CLI 的适用性，我认为它仍然是一种与 C++ 严格互操作的语言。 如果您正在编写一个全新的应用程序，那么选择 C++/CLI 而不是 C# 的理由绝对为零。 正如我所说，它比后者使用起来有点尴尬。
I have used C++/CLI for a simulation project. My simulation engine that does the actual computation was an existing code base written in C++. I needed to have a GUI front-end for it, which I successfully coded in C++/CLI.
In my view, the language is just as easy to code in as C# albeit with a slight syntactical awkwardness. That said, the syntax is far simpler than that Managed Extensions thing that Microsoft came up with earlier.
One of the most powerful feature of C++/CLI has to be the ability to simply recompile your existing native C++ code into MSIL. Of course there can be hiccups, but for most applications it should be a trouble-free exercise.
As for the suitability of C++/CLI, I think it will remain strictly a language for interoperability with C++. If you are writing an altogether new app, there's absolutely zero reason to pick C++/CLI over, say, C#. As I said, it is a little bit more awkward to use than the latter.
我们广泛使用 C++/CLI。 我们使用它将老化的 MFC 应用程序拖入 .Net 时代，因此我们现在可以用 C# 编写大多数新功能，并通过包装本机类和编写新的托管业务对象，使用 C++/CLI 将其与旧版 MFC 代码集成。 在我们的旧程序集中，我们仍在用 C++/CLI 编写新功能。
我没有使用“托管 C++”的经验，但与 MFC 和 Visual C++ 相比，C++/CLI 使用起来很愉快。 它的语法比托管 C++ 或 Visual C++ 简洁得多，即使是初级开发人员也可以轻松掌握它。
C++/CLI 中有一些有趣的行为，例如当您将本机对象传递给托管类的方法时，它会在本机对象周围放置一个薄托管包装器（对开发人员不可见），只是为了进行调用，但该垫片对于程序集来说是私有的，因此不能从外部调用。 一如既往，有很多方法可以解决这个问题，但它在早期就让我们陷入了困境。
我们使用 Visual Assist X 进行重构支持（可接受），使用 MbUnit/Gallio 进行托管类的单元测试，使用 NMock 或 RhinoMocks 进行模拟框架。
总的来说，我想说该语言拯救了我们的产品，并使我们能够利用开发领域中正在发生的所有令人兴奋的新事物。 如果我们仍然只使用 Visual C++/MFC，那么我们将很难招募开发人员，并且 COTS 的选择比我们使用 .Net 时受到的限制要大得多。
We use C++/CLI extensively. We have used it to drag an aging MFC application into the .Net age so we can now write most new functionality in C# and integrate that with the legacy MFC code using C++/CLI, by both wrapping native classes and also writing new managed business objects. In our old assemblies, we're still writing new functionality in C++/CLI as well.
I have no experience with "managed C++" but C++/CLI is a joy to use compared to MFC and Visual C++. .It has a much cleaner syntax than either managed C++ or Visual C++ and we have had no issues at all getting even junior devs up to speed with it.
There are a very few interesting behaviours in C++/CLI like when you pass a native object into a method on a managed class, it puts a thin managed wrapper around the native object (invisible to the developer) just for the purpose of making the call, but that shim is private to the assmebly so cannot be called from outside. There are ways around this, as always, but it caught us out a couple of times early on.
We use Visual Assist X for refactoring support (acceptable), MbUnit/Gallio for unit testing the managed classes and NMock or RhinoMocks for our mocking framework.
Overall, I'd say that the language has saved our product and allows us to take advantage of all the new exciting stuff going on in the development world. If we were still using solely Visual C++/MFC then we'd have difficulty recruiting devs and be far more limited in out COTS choice than we are using .Net.
C++/CLI 将CLR 引入 FreeSWITCH 非常简单。 比处理托管 API 或使用 Mono 容易得多。
在此之前我最后一次使用托管 C++ 是在 2003 年左右。 我记得这有点痛苦，而且工作不那么顺利。
C++/CLI was excellently simple for bringing the CLR into FreeSWITCH. Much easier than dealing with the hosting API or using Mono.
The last time before this I used managed C++ was in 2003 or so. I remember it being somewhat of a pain and not working as seamlessly.