为什么WPF不像WinForms一样支持C++.NET？

Question

作为一个C++专家，这真的一直困扰着我。我一直很喜欢微软大约十年前提出的“语言无关框架”的想法。他们为什么放弃了这个想法？有人知道背后的原因吗？

-

---

我的猜测是C++编译器团队人手不足，同时维护两种语言（C++和C++/CLI）太过繁重。C++/CLI将在VS11中被淘汰，您将使用轻量级编译器扩展来编写COM对象，这在我看来更加明智（并且与C++/CLI一样.NET友好）。我更喜欢一个正确的编译器用于一种语言，而不是两种语言的虚假编译器。 - Alexandre C.

Answer 1

原因之一是C++支持实际上是两种语言的结合——本地和CLI变体。Visual C++团队承认这种额外的开发负担是MSBuild集成落后于其他语言的原因。

另一个原因与编译期间代码生成有关，这在C#构建中进行以支持绑定“魔法”。我发现即使在F#中，你也不会轻易得到它。

- Steve Gilham

Answer 2

如果是我，我的理由是不应该使用C++.Net来编写GUI界面。并不是要挑刺，也许有人能证明我错了，但我认为这不是一个好主意。我现在正在尝试使用它来开发一个应用程序，但开发速度比使用C#慢得多。我的感觉是，如果应用程序需要C++.Net或普通的C++功能，那么更好的做法似乎是创建一个DLL来处理重要任务，并与C#进行接口交互。

- Spencer Ruport

---

这是因为C#已经投入了所有的努力使其易于使用。如果他们愿意，他们也可以在C++上做到这一点。只是他们不想这样做。 - gbjbaanb

@onebyone：只有当它们有适用的差异时才会有所不同。例如：Linq vs. F# vs. C#。否则，没有什么区别。我再也没听说过 J# 了，而 VB.Net 似乎日薄西山。如果你问 C++ 是否应该与 .Net 接口，那么是的。当两种语言都不知道其他任何数据类型时，这真的很麻烦。例如：C++ 直接使用 .Net 泛型字典可以节省大量时间，当你试图将其强大的功能与 C# 的易用性相结合时，这就是我上面提到的。但除了数据类型之外，我认为这是毫无意义的。 - Spencer Ruport

@onebyone：这并不总是一种错觉。起初，我认为J#、VB.Net、C#和C++都得到了同等的支持。您希望他们做什么？继续支持死亡或不那么受欢迎的语法（J#、VB.Net），并支持鼓励不正确使用语言的特性？还是应该继续开发有用的东西，例如LINQ、F#，并改进C#语法？（就我个人而言，我仍然对string MyProperty {get;set;}感到兴奋。） - Spencer Ruport

好的，微软有权定义“不当行为”。如果它想将C++作为GUI编程语言进行支持，那么它可以这样做；如果它更愿意鼓励应用程序开发人员采用C#，那么它也可以这样做。或者第三方可能会做出更全面地支持C++的工作，如果有需求的话。就我个人而言，我不介意：我不懂C#，但我也不编写.NET。我只是好奇风向在哪里。原则上，我对IronPython的兴趣比我对J# - Java的兴趣更大——Java还好，但C#已经包含了微软认为有价值的所有部分，所以它只是一个临时措施。 - Steve Jessop

如果他们要为不同的目的划分语言，那么他们应该全面推行 - 一个用于GUI，一个用于数据操作，一个用于数据访问.. 想象一下每种语言可以多么流畅。 - gbjbaanb

Answer 3

我也很不爽，如果他们支持的话，我们就能更容易、更便宜地将我们的 C++ 代码迁移到新的 GUI，而不是在 C# 中基本上重写所有内容。这让我们在经济衰退时付出了巨大的代价。

我想这样做的原因可能是因为 C# 很受欢迎（并且不像 C++ 那么跨平台），所以他们决定保持最低限度的开发工作。

- gbjbaanb

Answer 4

你可以使用托管C++来进行WPF开发。

原因是现在几乎所有的新应用程序编程都是使用JavaScript、Java、VB.NET或C#等GC语言完成的。重点是提高质量，降低技能要求，而C++对开发人员的要求过高，公司希望员工在第一天就能写出无错代码。

C++主要用于维护现有应用程序或需要极高性能的场景。设备驱动程序和操作系统仍然经常使用C++编写，但即使这也在改变（Coyotos是Cbit，E#，Cosmos/Mosa是C#，Singularity/Midori是C#）。

- Benk