为什么WPF不支持C ++ .NET-- WinForms的做法？

Question

作为C ++的坚持者，这真的让我烦恼。我一直很喜欢大约十年前微软提出的“与语言无关的框架”的想法。他们为什么要放弃这个想法呢？有谁知道它背后的原因？

Answer 1

部分原因是C ++支持实际上是两种语言 - 本机和CLI变体; Visual C ++团队已经承认额外的开发负载是正确的MSBuild集成滞后（滞后？我没有在2008年或之后检查过）其他语言的原因。

另一部分将与编译期间的代码生成有关，该代码生成在C＃构建中进行，以支持例如具有约束力的“魔力”;我发现即使在F＃中，你也不会“正好发生”。

Answer 2

如果是我，我的理由是C ++ .Net不应该用来编写GUI。

我不是想在这里嗤之以鼻，也许有人可以向我展示我的方式的错误，但我认为这不是一个好主意。我现在正在搞乱一个，并且开发速度比使用C＃编写的应用程序慢得多。我的感觉是，如果应用程序需要C ++ .Net或常规C ++中的功能，似乎更好的想法是创建一个DLL来完成繁重工作，并且可以与C＃进行交互。

Answer 3

它也让我感到烦恼，如果他们支持它，我们就能够比基本上重写C＃中的所有东西更容易和更便宜地将我们的C ++代码迁移到新的GUI。我们花了很多钱来修改我们的应用程序，这正是我们在经济衰退中想要的。

我认为理由是C＃很受欢迎（而不是C ++的跨平台），因此他们决定将开发工作保持在最低要求。

Answer 4

您可以使用托管C ++执行WPF。

原因是几乎所有新的应用程序编程现在都是用JavaScript，Java，VB.NET或C＃完成的 - 所有GC语言。重点在于较低技能的较高质量和开发人员对C ++的过多要求，公司希望人们在第一天编写日志错误代码。

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