我听说微软将把重点放在C#上而不是C++上用于.NET平台.我可以看到这是正确的迹象,因为GUI设计器可用于C#而不是C++.
所以我想知道.NET中的C++是否正在消亡,以及将来它是否会继续成为C#的第二位.
Ser*_*uei 24
如果您在应用程序开发中瞄准.NET框架,那么与C#相比,C++/CLI是第二类公民.C#专门设计为.NET框架的语言,同时C++/CLI扩展允许开发人员桥接本机代码和托管代码.
但是,不要将C++与C++/CLI混淆(C++ .NET也是一样的......).C++在内核,游戏,高性能和服务器应用程序(例如SQL服务器)等领域都很活跃,所有这些都不太可能改变.另一方面,大多数.NET'GUI stuff'都不会使用C++.
托管C++永远不会真正成为MS认为的那样.C#可以做(几乎)相同的事情,具有更直观和用户友好的语法.
除此之外,C++/CLI将不会长时间不受支持,因为它是在.NET程序集和本机C++程序集之间创建互操作的简便方法.这就是它所用的全部内容(我确信有0.001%的C++/CLI开发人员不同意:P).
C++/CLI就是Microsoft将本机C++开发人员引入.NET的方式.它就像是原生C++和C#之间的中间层,但我很确定开发人员更喜欢选择本机C++或C#.
微软不会让C++/CLI死掉,至少在不久的将来,如果没有社区支持,C++/CLI将无法发展.
在这一代人中,没有成长意味着接近死亡.
我很害怕.
其原因不是C#(它没有带来任何特殊的东西,虽然它是一种新语言,它不会引领新的语言功能,只是复制其他语言的功能 - 泛型).
这主要是因为MS首次尝试为.NET平台启用C++ - 托管C++ - 是一场灾难.
在此之后,他们聘请了C++大师Herb Sutter,这使得管理C++替代调用C++/CLI做了出色的工作.为什么以及有多少C++/CLI设计优于Managed C++设计,您可以通过阅读Herb编写的C++/CLI的设计原理来了解.
顺便说一下,Herb使vc编译器成为Windows最好的符合标准的编译器之一,因为它在标准一致性方面是多年来最糟糕的编译器.
| 归档时间： |
|
| 查看次数： |
5828 次 |
| 最近记录： |