| 发表于:2007-03-15 12:39:4572楼 得分:0 |
> 最好是开源,还能自己修改修改 atl server 已经发布到共享代码网站codeplex.com。在那里你还可以找到其他微软的共享代码。 基于显而易见的原因,微软不会发布和支持第三方代码编写的程序。 > 最好是ms下一年开发平台的主流,至少应该象现在的vc6一样,有这样强的生命力。 vc6的成功也可以看作是后续版本的失败。微软的目标是不断提升用户体验,发布更好的版本来促进用户升级。 > 功能应该更灵活,不要拖来拖去的form.可以定制窗口控制的绘制,能够增强gdi+功能。 微软的目标是减少程序必须编写的代码数量。这包括提升程序员的设计体验,用设计器生成代码。用户可以在设计器生成的代码的基础上进行自定义,或者自行编写绘制代码。 > 下一代vc最好多一些控件,再多一些皮肤控件 mfc的控件基本都是对windows控件的再封装。具体封装windows的那些功能则视用户的使用频率和需要投入的成本而定。另外,orcas增加的控件大部分只能在windows vista上使用,而目前编写只面向windows vista的程序还不太现实。 从windows xp开始通用控件都支持主题。 > 一个整洁快速的ide,虽然vc2005和vc2003的ide功能已经不错了,但是太多的功能导致有时候无所适从,甚至不能够直接把注意力转移到代码和软件开发上来。 微软的目标是提升程序员的生产力。对于不同的任务,程序员应该从各种功能中选择最合适的工具。 > 虽然现在的vc可视化方法,mfc沿用以前的方式,winform使用了.net framework,但是希望在开发的时候在winform和sdk,api之间构架一个新的for vc的ui框架中间层。使得winform for vc开发摆脱.net framework 这个属于api组的问题。.net framework和mfc都是应用程序框架,但是两者之间并不是互不兼容的,mfc8.0中包括了对windows forms的支持。为了vc一种语言而新增一个中间层在性能和成本上都不太现实。 > 对于webservice,xml,正则表达式等开发,能够提供效率高而稳定的api,而不仅仅是com组件,与web开发的协同和部署处理要增强,比如web service。 com的后继者.net被设计来处理这样的问题。你可以在visual c++程序中调用.net framework. > 多学学delphi 每个工具有不同的用户群,用户也会根据不同的任务选择不同的工具。把工具作得一模一样并不使大家都喜而乐见的。 > 内存管理方面能不能够参考java的方式,由系统来回收垃圾? 目前已经有不少第三方c++库支持这个功能。当然,你也可以到connect.microsoft.com去许愿。 > 我还认为应该简化vc的一些函数,比如int multibytetowidechar( uint codepage, // code page dword dwflags, // character-type options lpcstr lpmultibytestr, // string to map int cbmultibyte, // number of bytes in string lpwstr lpwidecharstr, // wide-character buffer int cchwidechar // size of buffer );这个wide <--> ansi的转换应该提高智能化 这个函数不是visual c++内的,而是windows sdk的一部分。visual c++中提供了很多api的封装类和宏。具体封装windows的那些功能则视用户的使用频率和需要投入的成本而定。 〉希望安装不要那么大,vs2005都上g了 visual c++ 6.0也不小,好几百兆。/ > 下一代vc首先不要占用太多资源,至少也要提供一个很明确的用户可配置的启动选项,可以根据自己的需要选择启动那些功能 visual studio的ide是面向多种语言的,不过精简版的visual c+ express也已经发布。用户可以选择启用/禁用很多功能,包括智能提示等等。 > 集成驱动程序开发 可以参考windows ddk的示例程序。 > 要求硬件不要那么高,好象ms的东西就是用硬件堆出来的 正在改进 〉 "orcas " 可以摆脱 .net framework进行开发吗? 在可见的未来微软不会放弃对非托管编程的支持。 〉if could, microsoft can provide a portable library based on "orcas " or "hawaii " for migrating the older vc++ code? visual c++文档中有升级指南,ide也会升级旧版本的工程,但是自动转换的危险性太大,建议还是手动对代码进行修改。 > 我觉得应该帮其中的帮助做的再专业一些,最好都有点小事例,要不刚开始的人真的摸不到头脑 最近示例的确比以前了一些,但是编写过多的示例也会影响到开发进度。 > 编译器编译速度快一点! 编译器正在重写以充分利用多核cpu。 > ide保持與vc6的一致性就差不多了 200x雖然通用 但實際上只是強迫所有人都用vb的ide 顯然非常多的人(個人以爲是大部分)厭惡這種做法 從200x發佈以來這幾年 我到過的公司基本上在用6(包括現在的公司) visual c++ 2005已经在这方面做了很多改进。但是由于要和其他语言使用同一个界面,很多方面要进行妥协。 > 另外ide響應速度也要提高 正在这方面努力。目前的考虑是充分利用多核cpu,以及使用线程来提高响应速度。 > 綜合這兩點 建議ide還是不要用.net來寫了 ide不是.net程序,甚至都不是unicode程序。 > 加强数据库功能 视封装数据库api会给用户带来多少价值而定。 > 接分 不劳无获 > 重要的是价格 这个是市场部的事情 > 希望 文本编辑器 能够开放比如有人喜欢用notepad,editplus,vim之类的来写东西,老切换来切换去,麻烦 你可以在ide中添加工具菜单来编辑当前文件。 > 好的设计关键不是增加了多少新功能,而是在于没有什么可减的功能。 每个用户的需求不同。用户越多,对于功能需求的分歧就越大。 > 个人觉得更符合c++标准就可以了。不要像c++ .net, 怪胎。 希望c++0x标准在下一代visual c++进入功能冻结阶段之前被通过。 〉希望vc能在界面编程方面改进,现在写一个酷酷的界面用vc实在太累了 就我的经验,程序员很少同时也是艺术家。或许你需要的是microsoft expression和wpf。 > 还有多线程调试时很容易死。这个能改进一下吗? 请去connect.microsoft.com提交bug报告。 > 希望提供wpf的c++接口,最好是net架构之外的 这个属于sdk组的问题。微软建议使用托管api来访问wpf。不过这也不妨碍你直接调用desktop window manager来访问同样的api。 > 取代 va 的功能,重构功能 一些微软的合作伙伴开发这样的工具,例如devexpress的refactor! for c++。 > 希望作到60m以下,我经常在网吧写程序,不方便安装。 或许你应该考虑学校的计算机房或者自己买一台计算机。微软提供virtual lab以供用户体验软件,但是服务器远在美国,国内访问速度太慢。 > 希望彻底淘汰mfc,进入.net时代 visual c++的使用者中有很多在mfc的基础上构建了很多应用程序。淘汰mfc会使得这些用户需要重新编写代码,这对用户的冲击太大。 〉界面及控件能不能更简单化,能做到象vb那样吗?这样我们就不会在界面和控件上花那么大的时间了其它的vc6就可基本满足了 你应该根据你的需求选择合适的工具。 > 集成wpf,多支持一些界面库,类似c++ widget 微软的调查结果是托管代码大多使用c#进行开发。微软会改进托管代码和非托管代码之间的互操作性,但是基于时间和可用的资源,不是每个语言的功能都会在c++中被支持。 > c++0x标准快要推出了,不知道这方面新一代vc会不会采纳? 在标准通过之后会根据用户的需求决定。 > 希望 ms 主推这门语言,至少也是要和 c# 并列 由于要符合c++标准的原因,不能像c#那样不断修改。 〉去掉恶心的stdafx.h 简化一些又长又不常用的宏(看着都不顺眼) stdafx.h默认被启用以加快编译速度。但也可以被禁用。 宏被用来提高程序的性能,你也可以不用宏,自行手动扩展宏。 〉我希望下一代vs是一种 "自然语言编译器 " > 最好支持 语音识别 > 这样写程序只需用口不用手了。 世界上没有这样的自然语言可以让各国程序员都可以用来编写程序。 > 把设计模式加进去。 在visual c++ 2005中可以使用code snippet重用代码,使用refactor! for c++重构代码。 | | |
|