是 C++ .NET 即将消亡？
我听说 Microsoft 将把精力集中在 .NET 平台的 C# 而不是 C++ 上。 我可以看到这一点的迹象，因为 GUI 设计器适用于 C#，但不适用于 C++。
所以我想知道.NET 中的 C++ 是否正在消亡，以及未来它是否会继续仅次于 C#。
I heard somewhere that Microsoft will be focusing their efforts on C# rather than C++ for the .NET platform. I can see signs of this being true because of the GUI designer that was available for C# but not C++.
So I would like to know if C++ in .NET is dying and if it will continue to be second to C# in the future.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
如果您的应用程序开发目标是 .NET 框架，那么与 C# 相比，C++/CLI 是二等公民。 C# 专门设计为 .NET 框架的语言，同时 C++/CLI 扩展允许开发人员桥接本机代码和托管代码。
但是，不要将 C++ 与 C++/CLI 混淆（C++ .NET 是同一件事......）。 C++ 在内核、游戏、高性能和服务器应用程序（例如 SQL 服务器）等领域表现良好，所有这些都不太可能改变。 另一方面，大多数 .NET“GUI 东西”不会使用 C++。
If you are targeting the .NET framework in application development then yes C++/CLI is a second class citizen compared to C#. C# was specifically designed as the language for .NET framework meanwhile C++/CLI extension is there to allow developers to bridge native and managed code.
However do not confuse C++ with C++/CLI (C++ .NET is the same thing...). C++ is alive and well in areas such as the kernel, games, high-performance and server apps (e.g. SQL server) all of which are unlikely to change. On the other hand most .NET 'GUI stuff' won't use C++.
托管 C++ 从未真正达到 MS 所想象的那样。 C# 可以做（几乎）同样的事情，但语法更加直观和用户友好。
除此之外，C++/CLI 不会在很长一段时间内不受支持，因为它是在 .NET 程序集和本机 C++ 程序集之间创建互操作的简单方法。 这就是它的全部用途（我确信有 0.001% 的 C++/CLI 开发人员不同意 :P ）。
Managed C++ never really got to be what MS thought it would be. C# could do (nearly) the same thing, with a lot more intuitive and user-friendly syntax.
Apart from that, C++/CLI will not be left unsupported for a long time, as it's the easy way to create interop between .NET assemblies and native C++ assemblies. That's about all it's used for though (I'm sure there's a 0.001% of C++/CLI developers out there who disagree :P ).
C++/CLI 正是 Microsoft 吸引本地 C++ 开发人员使用 .NET 的方式。 它就像本机 C++ 和 C# 之间的中间层，但我很确定开发人员更喜欢选择本机 C++ 或 C#。
微软不会让 C++/CLI 消亡，至少在不久的将来，但是，如果没有社区支持，C++/CLI 将无法发展。
在这个时代，不成长就意味着死亡。
C++/CLI is just the way Microsoft attracts native C++ developers to .NET. It was like a intermediate layer between native C++ and C#, but I'm pretty sure that developers prefer to choose either native C++ or C#.
Microsoft will not let C++/CLI die, at least in near future, however, without community support, C++/CLI will not be able to grow.
In this generation, not growing means close to dead.
恐怕是的。
其原因不是 C#（它没有带来任何特别的东西，虽然它是一种新语言，但它并没有带来新的语言功能，而只是复制其他语言的功能 - 泛型）。
这主要是因为 MS 第一次尝试为 .NET 平台启用 C++ - 托管 C++ - 是一场灾难。
此后，他们聘请了 C++ 大师 Herb Sutter，他在设计称为 C++/CLI 的托管 C++ 替代品方面做得非常出色。
C++/CLI 设计优于托管 C++ 设计的原因和程度，您可以通过阅读 来了解Herb 编写的 C++/CLI 设计原理。
顺便说一句，Herb 使 vc 编译器成为 Windows 上符合标准最好的编译器之一，而多年来它一直是标准一致性方面最差的编译器。
I'm afraid it is.
The reason for this is not C# (which doesn't bring anything special and although it's a new language it doesn't lead in new language features but merely copies features of others - generics).
It's mainly because the first attempt of MS to enable C++ for .NET platform - Managed C++ - was a disaster.
After this they hired Herb Sutter, C++ guru, which made fantastic job designing Managed C++ replacement callled C++/CLI.
Why and how much C++/CLI design is superior to Managed C++ design you can find out by reading A Design Rationale for C++/CLI written by Herb.
By the way, Herb made vc compiler one of the best standard-conforming compilers for Windows after years of it being the worst one in regard to standard conformance.
不，它一出生就死了。 它一直被视为没有活力路线图的二等公民。
No. It was born dead. It always has been treated as a second class citezen with no vitality roadmap.
我认为是的，它快死了，实际上它已经死了;)，因为没有很多人使用它，他们使用 c++ 还是 c#。
请参阅此
i think YES , its dying , actually it already died ;) , coz there arent lots of people who use it , they use whether c++ or c#.
see this
我认为它不一定会消失，但使用它的原因几乎总是取决于您是否需要它带来的性能优势。 如果 C# 能以 C++ 90% 的效率完成同样的事情，那还不够好吗？
I don't think it's necessarily going away, but the reason for using it almost always comes down to whether or not you need the performance benefits that come with it. If C# can do the same thing at 90% of the efficiency of C++, isn't that really good enough?