我是一个长在C++下,活在.NET里的初级程序员。公司用C#做企业开发。我确立的发展方向和爱好是逻辑算法和人工智能方面,还有游戏。这就决定了我还是得学习C++。我一直都想转到C++.NET上来,可托管C++实在……大家也知道。现在传闻VS2005中已完全修改了VC,叫C++/CLI。让我产生了好多疑问和疑虑,极度迷惑中,向请教各位。1.C++/CLI真的可以达到VC6.0的底层控制能力,而不影响C++的性能优势吗?真的超越了托管C++吗?2.在VS.NET2005中,MFC已经没有了吗?Longhorn中是不是已经不再用以前的"win32"API了?    如果C++/CLI真的一点也不削减C++的性能优势,我一定会选择它。但我想知道学习C++/CLI还需要学习MFC和win32API吗?如果在Longhorn下开发呢?    还有一个传闻:MFC将被淘汰?我不太相信。但我看到C++/CLI大张旗鼓地来,就开始怀疑有没有继续学习MFC的必要了。想请教一些分析人士。
    非常感谢!

解决方案 »

  1.   

    唉!又是新技术!头痛!等春节的时候在家研究研究吧!不过总的我的感觉是不管什么东东,微软不会不使用WinAPI,只可能扩展它或者是更深的封装它,让程序员更容易使用,但是也让程序员更迷茫,呵呵!学习WinPAI编程只是学习一种学习方法,永远不要觉得学了什么语言、什么编程方法就可以了,其实我觉得培养一种思考问题的方法,养成一种良好的编程习惯,一种学习方法更为重要!
      

  2.   

    我也和你一样!
    我以前是搞java的,只是想在图形方面发展!
      

  3.   

    我晕,,我都没听说过。。搞游戏开发不是用Direct X吗??
    微软啥时候转风向了???
      

  4.   

    驱动开发不是用DDK吗?,还有啥东东是要这么的要性能的?我感觉涉及底层的就驱动和Direct X了啊!
    请各位大哥指点。
      

  5.   

    Longhorn应该是可以用API
     我看MSDN时 SetWindowLong() 32BIT
              对应有SetWindowLongPtr() 64bitThis function has been superseded by the SetWindowLongPtr function. To write code that is compatible with both 32-bit and 64-bit versions of Microsoft® Windows®, use the SetWindowLongPtr function.
      这句话是什么意思? 我没大看懂我感觉学MFC 还真不如学。NET ,但是学。NET 真的像赌博,人人都学? 那到时。 我不管了,先继续研究半年API 在说~MFC将被淘汰? 应该会被MS冷淡, MS怎么对待VF?还不有VF9,淘汰? 冷淡?我不清楚
     装做什么都不知道吧,继续学自己的~  我比较心黑,.net学了一年多了,但是也在学VC API 什么的,  脚踩两条船,我用2倍时间学不行吗, 妈滴,我就不信我是弱智,当然最终还是要放弃一样的  .net 肯定是趋势,但是我.net 真的看不惯,一个界面,绘制的时间有时都可以让人感觉到,内存狂吃,我也用了好多GC 回收~,还是这样~,但是开发真的是快
      但是我不甘心我为什么没有学API?
      

  6.   

    楼上的因为没有懂得如何使用。net。
    你的gc怎么可以乱用呢〉镇是伤脑筋阿。
      

  7.   

    在MS规划的未来里,.Net才是王道
      

  8.   

    我想CLI的优势在于灵活的协作托管、非托管编程。但业务软件的开发中C++效率太慢,C#应该还是正统
      

  9.   

    我个人觉得 C#/C++混合编程就行了C++/CLI  有这个必要吗?
      

  10.   

    MFC即使在2005还在继续改版,趋势是和ATL的融合现在的情况看在桌面应用下用C#是不太可能的,现在的PC一般是256MB的内存但很多人已不满意,CPU也是资源也是,对于现在的应用来说并不充寓,托管的性能可能不太会被接受.
    托管的代码容易反编译,这对于大规模发布的软件来说是致命的,混淆器在一定程度上解决了问题,但这牺牲了程序的性能和稳定性.
    现在的软大多是旧版本的升级,如果用C#就等于完全重写,这对于一般的公司来说是不能接受的,这也是Managed C++的使命.
    以我的感觉,在桌面应用上C++/CLI在性能上和代码安全性的优势不可替代,在灵活性上,像Photophop,FLASH之类的软件,C#恐怕很难完成.快速开发是个优势,可是以以快速开发著称的delphi,各位的电脑有哪些是用它写的?我的电脑上可能找不出一个,为什么?我也想不出.
      

  11.   

    说明一下,编译器的选项设置可以极大地影响程序的性能;例如是否产生调试信息、是否优化switch语句、是否使用浮点数指令集等等。当然,更影响性能的是代码中算法的优劣。至于选择语言的方法就见仁见智了,我个人选择使用.Net类库、MFC和C++/CLI编写多数界面程序,但是性能敏感的模块使用win32API、C和汇编。C++/CLI是托管C++的第二版,但是也未必是全面超越托管C++——至少不比托管C++更加遵循C++标准。Longhorn仍然支持绝大多数API——除非比尔盖茨疯了,想放弃市场。MFC的市场会减小,但是MFC会继续发展,就像汇编语言的市场虽然比以前小,但是还是在随CPU的升级一起发展一样。
      

  12.   

    对了蒋大哥,上次我的贴子再帮我看下好吗?
    http://community.csdn.net/Expert/TopicView.asp?id=4024319
    很奇怪的问题
      

  13.   

    1。C++/CLI支持托管与非托管并用,对程序效率不会有太大影响,其设计目的是为了让c++程序员能够较容易的转向.net,微软可不想放弃大量的c++程序员用户
    2。net2005中还有MFC