目前我分为这两种语言。我差不多编程了当前的应用程序，需要非常快。它可以在多种负载条件下计算任何类型的绝缘玻璃结构。
我只是不知道它是否是在C ++ / CLI中编写它的正确选择。例如，在互联网上，我甚至从未读过“C ++ / CLI”的名称，但每个人都建议学习C＃。
C ++ / CLI的缺点是什么？？我从阅读中得知，未来几年它注定会被弃用。这是真的？如果有一些，它们是如此糟糕，真的有必要切换到C＃？
目前针对C＃的唯一一件事就是我有C代码需要访问，而且由于安全问题和黑客攻击，我无法创建.Dll。 （该计划将非常昂贵）
为了编写在Windows上运行的快速GUI（还有3D动画和多核甚至图形核心处理），我还有什么其他机会？
答案 0 :(得分：3)
为了获得更高的性能，我已经将大量的C＃/ WPF UI移植到C ++ / CLI（与C++/CX相关，已经演变为WinRT）。重要的是要记住，它不是C ++，而是一组用于支持.NET的C ++语言的托管扩展。我喜欢低级UI编码，并且经常在WPF中编写大多数控件，源自DrawingVisual或UIElement，具体取决于用户输入要求。
我个人不喜欢'扩展'（比如使用帽子^）并且发现它非常不自然。我没有看到C＃带来的巨大收益（新发布的4.6看起来已经做了额外的改进）。我个人认为C ++ / CLI很快就会成为过去。我绝对不是一个人对C ++ / CLI的厌恶，像Kenny Kerr这样的人在整个问题上都有big impact。事实上，我预测MS将采用他的库和日落C ++ / CLI。
转储整个项目后，迁移到纯C ++ / Direct2D。我严重低估了开发时间，但我发现了巨大的收益。这不是一条简单的道路，因为您将编写自己的控件（文本框和所有）。但是现在有Win2D（Direct2D的包装器）提供了那些控件，并且看起来是一个很好的解决方案（但是当我开始时它不可用，我现在无意改变）。
我现在对自己的决定感到高兴，但我一直有些疑惑，并不一定会推荐这种努力，除非你的心脏长久真的运输。否则，坚持你所知道的。
编辑：顺便说一下，任何说C＃/ WPF的人都和C ++ / DirectX一样快，无论是拒绝还是妄想。通过VS2015中包含的一些优化器改进，您会惊讶于小尺寸和性能。删除.NET依赖是一个巨大的减重，同时使那些打算对产品进行逆向工程的人很难。
编辑2：如果你当前不知道C＃/ WPF，那么当然避免它，特别是因为你有现有的C代码（这就是我赞成Dave的原因）回答）。如果性能至关重要，现在是进入DirectX 12（MS技术的最佳性能）的最佳时机。祝你好运，听起来像一个有趣的项目。
编辑3：如上所述（关于Kenny Kerr），here是最近的公告，可能会开始新时代，而日落C ++ / CLI和C ++ / CX
答案 1 :(得分：0)
我sometimes of the opinion如果我们可以回头时间，那么可能没有C＃，因为C ++ / CLI可以（已经）完成这项工作。但是当我们得到C ++ / CLI（Visual Studio 2005，Managed C ++很糟糕）时，C＃已经非常成功了。
我将不得不寻找引用，但Microsoft当前（或至少是最近的）指导是C ++ / CLI现在仅用于“互操作”方案。这是从C ++ / CLI首次引入时的初始目标开始的相当大的一步;它原本打算成为C＃和VB.NET旁边的一流.NET语言。
我的经验法则是，如果我必须在C＃中复制头文件，那么C ++ / CLI可能更好。否则，如果它是一个“简单”（字符串，整数，双精度）P / Invoke到非托管代码，那就去吧。
答案 2 :(得分：-2)
这个想法认为C DLL不如CLI DLL安全 - 它来自哪里？在我看来，它完全是假的。逆向工程C DLL比任何IL代码都要困难得多。
我使用C ++ / CLI互操作到C库。我还为几个项目（like this one）使用了C＃interop stuff（aka，DllImport）。 DllImport比C ++ / CLI更容易。它允许你保持＆＃34;任何CPU＆＃34;目标;只需为每个目标平台包含一个本机DLL，并在运行时加载正确的DLL。 CLI中的固定很难做到。你最终得到了很多尝试/最终的东西。这是一个奇怪的运营商组合。