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?
C ++ / CLI是非常强大的语言。它是唯一可以无缝组合托管和非托管代码的CLR语言。有多少软件开发人员(在本网站上)使用这种语言?你在什么样的项目中使用它?它是遗留代码的修改还是原始软件的创建?你能比较旧的Managed C ++和新的C ++ / CLI吗?您如何看待C ++ / CLI的当前质量和未来?
4 个解决方案
#1
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.
最着名的独特功能是能够无缝地钻研非托管代码并在整个过程中修改(或意外损坏)任何可写内存 - 这在一般编程中并不是一个优势,但是当你需要它时,它很棒。但我想我会越来越少地需要它。您可以使用/ pure标志编译C ++ / CLI,但它确实成为一种全新的语言。
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.做有用的事情的析构函数。在C#中,析构函数是终结器。在C ++中,它是一个适当的确定性称为析构函数。这意味着C ++ / CLI具有最完整的基础结构,可以使用IDisposable。 C#仅帮助客户端(通过using语句),但只有C ++ / CLI也可以帮助实现者。我希望也许有一天C#会吸收这个功能。
-
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.
鸭子打字模板,可以与CLI泛型一起使用。另一件在C#中非常有用的东西,虽然它可以在没有历史包袱的情况下更加无缝地制作。
But C# is good enough without the last two things that I'm not tempted to use C++/CLI generally.
但是C#在没有最后两件事的情况下已经足够好了,我一般都不想使用C ++ / CLI。
#2
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.
我使用C ++ / CLI进行模拟项目。我实际计算的模拟引擎是用C ++编写的现有代码库。我需要有一个GUI前端,我在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.
在我看来,语言与C#一样容易编码,尽管有轻微的语法尴尬。也就是说,语法比微软早先提出的Managed Extensions简单得多。
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.
C ++ / CLI最强大的功能之一就是能够将现有的本机C ++代码重新编译为MSIL。当然可能会出现打嗝,但对于大多数应用来说,这应该是一个无故障的练习。
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的适用性,我认为它仍然是一种与C ++互操作的语言。如果你正在编写一个全新的应用程序,那么选择C ++ / CLI绝对没有理由比如C#。正如我所说,使用它比后者更尴尬。
#3
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.
我们广泛使用C ++ / CLI。我们使用它将老化的MFC应用程序拖到.Net时代,因此我们现在可以在C#中编写大多数新功能,并使用C ++ / CLI将其与传统MFC代码集成,包括本机类和编写新的托管业务对象。在我们的旧程序集中,我们仍然在C ++ / CLI中编写新功能。
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.
我没有使用“托管C ++”的经验,但与MFC和Visual C ++相比,使用C ++ / CLI是一种乐趣。它具有比托管C ++或Visual C ++更清晰的语法,我们甚至没有任何问题,甚至初级开发人员也可以快速使用它。
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.
在C ++ / CLI中有很少有趣的行为,比如将本机对象传递给托管类中的方法时,它会在本机对象周围放置一个瘦托管包装器(对于开发人员来说是不可见的),只是为了进行调用,但那个垫片是私人的,所以不能从外面调用。一如既往,有很多方法可以解决这个问题,但它很早就引发了我们几次。
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.
我们使用Visual Assist X进行重构支持(可接受),使用MbUnit / Gallio对托管类进行单元测试,使用NMock或RhinoMocks进行模拟框架。
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.
总的来说,我会说这种语言已经保存了我们的产品,并使我们能够利用开发领域正在发生的所有新的令人兴奋的事情。如果我们仍然只使用Visual C ++ / MFC,那么我们很难招募开发人员,并且在使用.Net时,在COTS选择方面的限制要远远超过我们。
#4
C++/CLI was excellently simple for bringing the CLR into FreeSWITCH. Much easier than dealing with the hosting API or using Mono.
C ++ / CLI非常简单,可以将CLR引入FreeSWITCH。比处理托管API或使用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.
在此之前的最后一次使用托管C ++是在2003年左右。我记得它有点痛苦而且无法无缝地工作。
#1
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.
最着名的独特功能是能够无缝地钻研非托管代码并在整个过程中修改(或意外损坏)任何可写内存 - 这在一般编程中并不是一个优势,但是当你需要它时,它很棒。但我想我会越来越少地需要它。您可以使用/ pure标志编译C ++ / CLI,但它确实成为一种全新的语言。
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.做有用的事情的析构函数。在C#中,析构函数是终结器。在C ++中,它是一个适当的确定性称为析构函数。这意味着C ++ / CLI具有最完整的基础结构,可以使用IDisposable。 C#仅帮助客户端(通过using语句),但只有C ++ / CLI也可以帮助实现者。我希望也许有一天C#会吸收这个功能。
-
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.
鸭子打字模板,可以与CLI泛型一起使用。另一件在C#中非常有用的东西,虽然它可以在没有历史包袱的情况下更加无缝地制作。
But C# is good enough without the last two things that I'm not tempted to use C++/CLI generally.
但是C#在没有最后两件事的情况下已经足够好了,我一般都不想使用C ++ / CLI。
#2
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.
我使用C ++ / CLI进行模拟项目。我实际计算的模拟引擎是用C ++编写的现有代码库。我需要有一个GUI前端,我在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.
在我看来,语言与C#一样容易编码,尽管有轻微的语法尴尬。也就是说,语法比微软早先提出的Managed Extensions简单得多。
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.
C ++ / CLI最强大的功能之一就是能够将现有的本机C ++代码重新编译为MSIL。当然可能会出现打嗝,但对于大多数应用来说,这应该是一个无故障的练习。
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的适用性,我认为它仍然是一种与C ++互操作的语言。如果你正在编写一个全新的应用程序,那么选择C ++ / CLI绝对没有理由比如C#。正如我所说,使用它比后者更尴尬。
#3
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.
我们广泛使用C ++ / CLI。我们使用它将老化的MFC应用程序拖到.Net时代,因此我们现在可以在C#中编写大多数新功能,并使用C ++ / CLI将其与传统MFC代码集成,包括本机类和编写新的托管业务对象。在我们的旧程序集中,我们仍然在C ++ / CLI中编写新功能。
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.
我没有使用“托管C ++”的经验,但与MFC和Visual C ++相比,使用C ++ / CLI是一种乐趣。它具有比托管C ++或Visual C ++更清晰的语法,我们甚至没有任何问题,甚至初级开发人员也可以快速使用它。
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.
在C ++ / CLI中有很少有趣的行为,比如将本机对象传递给托管类中的方法时,它会在本机对象周围放置一个瘦托管包装器(对于开发人员来说是不可见的),只是为了进行调用,但那个垫片是私人的,所以不能从外面调用。一如既往,有很多方法可以解决这个问题,但它很早就引发了我们几次。
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.
我们使用Visual Assist X进行重构支持(可接受),使用MbUnit / Gallio对托管类进行单元测试,使用NMock或RhinoMocks进行模拟框架。
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.
总的来说,我会说这种语言已经保存了我们的产品,并使我们能够利用开发领域正在发生的所有新的令人兴奋的事情。如果我们仍然只使用Visual C ++ / MFC,那么我们很难招募开发人员,并且在使用.Net时,在COTS选择方面的限制要远远超过我们。
#4
C++/CLI was excellently simple for bringing the CLR into FreeSWITCH. Much easier than dealing with the hosting API or using Mono.
C ++ / CLI非常简单,可以将CLR引入FreeSWITCH。比处理托管API或使用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.
在此之前的最后一次使用托管C ++是在2003年左右。我记得它有点痛苦而且无法无缝地工作。