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