回 帖 发 新 帖 刷新版面

主题:转载->"对VC的批判”->高手来评论一下这小子说的!

一家之言,VC高手不妨过来指点指点,没有人骂我,我不高兴

                               作  者:bitfan ()

注:以下的观点主要指VC6。)

1.       背景我这人喜欢偷懒,VC我断断续续学过很长的时间,最终没有能成为我想成为的那种高手,在“程序人生”中的一个贴子《怎样克服学习过程中的浮躁,来者有分》

(http://www.csdn.net/expert/topic/635/635462.xml?temp=.8159601)中我看到有很多人都说VC难学,信然!拿我来说,最终真正派上用场的还是VB和C++Bulder之类RAD开发工具。 我在想,为什么大家都在说VC难学,却又想学,许多人是不是都象我刚学VC一样,人云VC如何如何,就去学VC了,但水平与能力有限,只能成为半罐子水,花钱不少,花时间不少,花精力不少,代价更不少,却没得到什么…… 为什么大家都要“明知山有虎,偏向虎山行”?特别是许多准备进入软件开发这一行业的,用过自已的大脑仔细想过为什么要学VC吗? 我的观点要打击大家学VC的积极性了……

2.为什么用VC干活的人工资高?我认为学VC可以对一个程序员的基本功做出最痛苦的锻炼,所以经过VC苦练的人大都是金刚不坏之身,再学其它的东西就感到游刃有余了。通过VC成为高手者自然人少,以VC之难能成为高手者自然能力超群, 牛人自然工资高,这有什么奇怪的?他们付出了更多罢了。

3.不学VC的最主要理由:技术进步!不知诸位正在学VC的想没想过技术进步这个因素?如果你学VC是为了有个收入高的好工作,那么我认为你还是别学好。现在.net已经推出,编程平台的转移是必然的,这个周期大约就在两三年之内。 VC6的核心就是两大类库:MFC和ATL,前者是基于win32 API的一种FrameWork,后者是开发COM组件的类库,两者开发的是传统的Windows应用程序,学VC不学MFC,不学ATL几乎可以说没学VC!但遗憾的是学VC的人没有几个不为MFC中那些复杂的类之间的关系,那些奇怪的代码而头痛,ATL也好不到哪去,如果你事先没系统地学习COM理论,用ATL来发基于COM的组件几乎是不可能的。事实上,MFC框架就是一种设计模式,只不过微软的开发人员将其设计得非常完善罢了。那本著名的《设计模式》经典书中就介绍了23种设计模式,其中介绍的MVC模型几乎就是MFC的精髓!用MFC开发软件,你就必须遵循它的思路,你所做的工作就是在这个框架上修修补补,(当然,这个框架做Windows界面还是非常完善的,几乎考虑到了程序对界面的所有需求),但我觉得强迫别人按照一个框架去解决问题这是对人的一种束缚!可悲的是还有那么多人沾沾自喜于此!我常用C++ Builder,我知道VC的高手对这类RAD心存蔑视,但我也知道我在C++Builder中可以非常方便地从头开始应用一种设计模式,而不用费心地考虑如何将我这种设计模式嵌入到某个框架之中(当然我也可以设计出很复杂的应用多种设计模式的程序框架,C++Builder把这个工作留给了程序员自已);同样的工作,对于一个对VC不熟的人,自建若干个新类,再将其引入到MFC中不是一件简单的事,其主要原因就是MFC的复杂性。C++Builder中只需新建若干个Unit,然后写你的类,再在窗体上加一个接钮,包含上新类的头文件,new一个对象就可以用了,对于初学者而言,你说哪种解决问题的方法更直观,从程序设计的角度,哪一个效率更高?

4.从微软的策略看VC的前途!微软的策略是先用.net提供一个新的环境,然后逐步修改其OS,最终完全抛弃NT内核,其最终目的是抢占被UNIX和LINUX占据的高端市场份额(这是Borland李维说的,我觉得有道理)。现在推出的.net框架还支持原来的技术(如COM+),VC.net中也还有MFC7,但这只是一个过渡时期的产品,就象Windows 3.1被Windows 95取代一样,最终是要被抛弃的。很明显,软件发展的趋势就是不断提高软件开发的效率,在.net中开发程序绝不会有现在VC6中用MFC这样复杂和繁琐,事实上,新的平台已不再有win32 API这种平面型的开发接口,已全面立体化(类似于在C++的类库,使用方式也与C++中类的使用方式类似),而且应用程序又回到了DOS时代的简洁,只需复制整个文件夹,就可以移动一个应用程序,程序是自说明的,注册表也没有了,意味着基于注册表的COM组件技术也将被取代。这一切的变化周期估计就在两三年之内。

5.现实的考虑:诸位想想:如果你花一到两年的时间去学VC6,尤其是MFC,就算你到时是VC的绝顶高手,你却空有屠龙之技而无龙可屠,岂不悲哉!想想如果有一个DOS时代的高手跨越时空来到现在,他的技术早已被时代所淹没,如果不更新知识,他会发现要找到一个饭碗都不容易。对于所有想学VC的人,我提出一个忠告:VC的巅峰期已过。 那现在为什么还有那么多公司想要招VC的程序员?有很大的原因是对过去资源的继承。过去的投资不能白费,这还用说吗?

6.如果你打算学VC,请端正你的目的!现在学VC的目的不是为了好找工作,好拿高薪,而是因为它的复杂是锻炼一个优秀程序员的最佳方法,就象奥运长跑选手为了提高身体素质而到高原上训练一样。对于想进入软件开发大门的人我的建议是直接学习最新的技术,而且最好是现在学习今后一到两年内会成为主流的技术,而那些有志于成为windows软件高手的人,VC是必修课,不经百炼哪能成钢?而且VC肯定还会生存很长一段时间,就象现在还有用Foxpro开发的系统一样.

7.我学软件喜新厌旧:对于象我这样的平庸之辈,我脚踏N只船:最早以VB入门,从3.0用到6.0,它给我带来的收获也最多;VC我是半桶水,学了一两年就没一点成就感;C++Builder是我的爱将,是我学习C++和各种软件理论最常用的开发工具,用它也做了不少东东;真的不错,准备娶过门来了;我还对Java心存向往,很想马上去学,不过个人能力有限,还是放一放罢…… 掌握多种开发工具有一个好处,那就是可以取长补短。比如有一个图象处理程序用VC开发,而其中的报表部分我则用C++Builder做出来,再以COM组件的方式给VC调;要操作Office我喜欢用VB,要写多层系统访问数据库我喜欢用C++Builder(现在还加上Delphi),所有这些都可以在COM的基础上统一起来…… 不过COM也快完蛋了,我也要学新的东东了,可惜了我买了那么多COM的书……对了,还要加一句,对COM了解即可,别钻进牛角尖里去了,COM又是一个无底洞,也许日后再发个贴子,就叫"对COM的批判"



谢谢horris(僧推月下门)的高论。 我想就horris贴子中涉及到的几个方面谈谈看法。

1)程序框架和设计模式: 程序框架的设计体现出设计模式理论,可以看成是一个未完成的系统,程序员在这个框架之上加入实际工作的代码而形成真实的系统。而这两者的出现与广泛应用是软件开发走向成熟的必然。 为什么要提出设计模式理论和应用程序框架?很简单,就是要提高软件产品的质量和生产率。 现在主流的开发工具中都有程序框架的应用,最典型的是MFC和VCL。那么,衡量一个框架好坏的标准是什么?我可以列出几条,但我可以肯定地指出,框架的可复用性是第一位的,而易用性是第二位的,运行效率则是第三位的。就可复用性而言,MFC和VCL难分高下,而易用性则差别巨大,我就不详细说了。    

2)“运行效率”vs“开发效率”; 运行效率和开发效率这两者谁更重要? 除非是开发实时系统和某些系统核心模块(这种模块在整个项目只占很小比例),大多数软件项目考虑的是开发效率和一些其它因素,对运行效率则要求不高。 所以,象开发效率、稳定性、易用性、易维护、可扩展等就成为首要考虑的因素,而运行效率则是在保证达到前面要求的前提下再去考虑的。 另外,是否VC做出来的东西就一定好和快呢?这取决于系统设计和程序员对语言和工具的把握程度。 举个例子: 在程序设计过程中,都要对系统功能进行封装。假设系统中要将ADO RecordSet封装成一个适合特定用途的数据存取类,用VC封装工作量是C++BUILDER的好几倍(因为C++BUILDER中有一个现成的类TADODataSet封装了ADO RecordSet,基于TADODataSet自然要少很多工作),除了少数VC高手,绝大多数人用VC实现的封装都无法与用TADODataSet的封装相比拟,为什么?很简单,你对原生的ADO RecordSet的封装达不到TADODataSet的水平!开发VCL的程序员是一批牛人,这批牛人的水平是绝大多数程序员所无法达到的,牛人们既熟悉语言和开发工具,也熟悉ADO的底层原理。你用VC做出的东西,与另一个用C++BUILDER或Delphi做出来的东西相比,可能你的稳定性更差,运行速度更慢! 既然费尽心机地用VC做出来的东西还不如另一个学了Delphi3个月作出来的东西,我为什么一定要哪壶不开提哪壶? 所以,从现实的角度,我不赞成大量的程序员为了“自己造轮子”而将大量精力花费在VC上,应尽可能地复用优秀的软件组件。 开发效率是程序员吃饭和公司生存的关键因素。

3)关于.net平台下的Unmanaged和managed应用: 毫无疑问,Unmanaged程序肯定快,但我可以肯定的说,managed今后将会大行其道,特别是在企业级信息网络中。 什么叫Unmanaged应用?直接调用OS的API,直接编译生成机器码的程序。而managed应用,就是运行在一个软件虚拟机上的程序,Java就是一个典型的例子,.net也是走的这条路!Java为什么这样火,M$为什么要跟进这个步伐?很简单,这种架构更适合于现代信息网络的要求。VC6只能开发managed应用,你说说它在现代的网络化软件中会居于一个什么地位? 另外,在企业级的软件中,最重要的是什么?一个是安全,另一个是集成多种信息源!运行效率的考虑是放在最后的。Java慢,但为什么还被广泛用来开发企业级应用程序?XML和Web Service为什么被称为下一代网络技术的核心?最关键的一点是它可以使不同平台的软件相互合作!

   4)现在可以做出一个小结: 对于需要高效率、与硬件打交道、运行于传统Windows平台下的程序而言,VC是重点选择的开发工具,有志于此的程序员必须花大力气去学VC; 对于开发企业级软件和电子商务等互联网应用领域的专业程序员,根本不要去学VC,而应将精力放在标准C++,Java,C#等语言的学习上,同时重点学习.net、J2EE等平台; 对于一般的软件开发爱好者来说,VC不是必经的一条道路,可以根据实际情况选一种开发工具和语言学习; 对于还在学校学习的计算机专业学生,C++和Java是必学的,至于VC,需不需要学还要看你将来想从事的领域。 我之所以发这个贴子,是看到有很多贴子总在夸耀VC的强大(这是实情),无形之中很多人被误导了,不管什么情况,好象一学软件开发必学C++,一学C++必学VC,然后浪费大量的时间和金钱于此,费事不少,收效则低!(我周围就有很多这样的情况,包括我,都成为VC的半瓶水)先不说成为不了专业程序员的人,就是以软件开发作为职业的人,从事的领域不一样,也不一定非学VC不可。有这时间,干些别的岂不更好? 至于VC的前景,我在本贴中提出了自己不乐观的看法。诸位兄弟姐妹想必会有更多的观点,我希望大家能多多讨论一下,这不是孰优孰劣的问题,而是如何把握技术发展趋势,然后根据发展趋势来选择自己的突破口的问题。如果有多方面的观点,对大家想必都是一种启发。 期待更多的发言

回复列表 (共77个回复)

21 楼

WX:
建议你再去补习一下文科,我说:"如果C已经足够了,那么花人力物力去搞一个C++干嘛"是针对你说的话说的,你没有看到"如果"这个词?你却把它理解成"有c已经足够了,干吗要去搞c++,"
至于"适合明星的不一定适合自己"是广告语,你没有见到我用引号引起来了吗?我只想说明只要我自己用合适我自己的程序工具就可以了,没有必要一定要选什么VC.是根据你说的"所以就有人意志不鉴定随波逐流,抛弃原来的信念。"说的.

我不清楚你的VC语法写得怎么样,但是对于你的语文我真是无话可说了.

22 楼

在此我抱歉

23 楼

WX:
我承认我21楼的话有点过分,所以我很早就起来了,想道个歉.
就算再严重也没有你说的那样吧?
你看看你自己说的也很不尊重人.
我说我的朋友,是想说明,没有盲目的强人.

我只是想就你在16楼说的,你说要搞某某的精髓出来才有发言权,是你不给别人说话吧?另外,你说你是一个VC的疯狂爱好者,学了几年时间还达不到预期的效果,可能你谦虚了.但是又说很多人用VB,DELPHI写出让人眼花缭乱的程序来....写得出是罪过,写不出来反而是光荣了?
你说出了MFC很多的优点,但是只字不提别的工具.要说封装,MFC比不上VCL吧.MESSAGE MAP BCB也有的.

最后,我承认我偏激,本来不应该对这些说这么多的.存在就是道理.
我的偏激来源于见到我国培养的考试型人才比实用型人才多,我的偏激来源于上机考试的时候只能使用PASCAL做数据结构而不能使用C.

24 楼

公说公有理,婆说婆有理!
其实大家心中都有一个自己觉得得心应手的工具。
最重要的是大家的思想。
工具有差异,考虑一个现实问题,解决这个问题的思想不受工具的影响啊。
这样的争论也挺好,标记下来。

25 楼

x_uy_u_n:
   其实我说句实话,你说的对,我的语文水平真的很差,我在18楼说的话,是我的语言没有组织好,其实我说的话真的没有你理解的意思,我只以我的经历来看待问题,其实我说的是我周围的一些人,在他们还没有学好一个与语言和工具的时候,看见别人他们熟悉的工具编出好的程序的时候,他们就放弃自己还没有学精的东西,转投另一个语言和工具。我认为这样的做法是不正确的。但是我并没有看不起别的语言,可能又打个你不喜欢的例子,盖茨在一开是的时候,只是用basic语言,很多人都瞧不起他,但是他没有放弃自己的想法。其实,我真的没有别的意思,但是我不太会表达。我知道,我毕竟还是个学生,可能你的见识要比我的多,所以更有发言权。
   mfc其实真的没有那么强大,也没有那么完美,他比bcb等,有些地方就像windows一样漏洞很多,但是他幸运的是,他搭上了ms这条航母。我现在对其他的工具,根本就不了解,所以我也不能忘加评论。不打不相识,可以较个朋友么!

26 楼

x_uy_u_n 和wx:      
         我已经看过了两位大虾在楼上发出的所有的帖子。恕我直言,两位的讨论和争执已经远离了正轨。
    我想我们大家都是编程爱好者,最多也就是个技术研究者,而不是理论研究者,更不是所谓的社会活动家、政治家、思想家了。我们这个论坛也只是个纯粹的技术论坛,而不是科学论坛,更不是社会论坛了。那么我们在这里所展开的一切活动都应该围绕着编程的实际技术来进行,即便是大家要在这里开展论战也不应该以“说服对方接受己方的观点”为目的。我想我们大家的辩论也应该以切磋技术、提高自身的业务水平、丰富思维和专业知识为唯一的目的。因此,大家在提出自己的观点的时候都应该以编程方面的客观事实和经验(经历)为依据,不应该把那些与编程无关的事实和自己的主观臆断作为依据。象两位这样把与编程无关的电影、电视方面的事实和观点作为讨论的依据和内容,甚至加入人身攻击方面的语言,不但会使我们的讨论远离正轨,而且会给看了你们的帖子的初学者留下非常不好的影响。
    你们在自己的帖子中引用了某部电影里面的一个特定的情节。而据我所知,你们所提到的那部电影在美国是作为三级片而受到放映限制的!电影发行公司钻了我们国家还没有建立电影分级制度的空子,狠狠地在我们的青少年观众的身上赚了一把,这已经是我国民之不幸了,而你们偏还要列举其中的那个敏感的情节。浏览这个网站的人有许多还是在校的学生啊,这怎么不让我耽心?
    最后我强烈恳求两位大虾把你们自己在楼上发表的那些帖子撤下来,还给我们的初学者一个清新的版面!

27 楼

wx:
         我的确曾经作过这样的努力:自己编写一个类库以便象MFC那样实现对windows API函数的封装。那时候我还很年轻,而且我已经习惯了使用SDK方法直接运用windows API函数编写windows程序,所以对MFC的流行心生不满。我当时作的第一件事便是写一个象MFC中的CWnd那样的窗口类,来实现对所有窗口API函数的封装。就象你所猜想的那样,我的工作刚刚起步就在消息映射这个环节上碰到了麻烦。
    按照我的想法,我的窗口类应该使用其成员函数来处理windows窗口消息,并且还应该让它的继承类也可以用成员函数来处理这些消息,就象CWnd类那样。但是用于创建windows窗口的API函数CreateWindow和CreateWindowEx都不接受我把我自己的窗口类的一个成员函数作为其窗口消息处理函数的想法。我的窗口类在编译的时候总是出错,而且错误信息似乎与this指针有关。为了解决这个问题,我查找了许多资料,最后终于找到了问题之所在。
    程序在调用类对象的成员函数的时候都要给该成员函数隐式地传递一个指向本对象自己的this指针,以便让被调用的那个成员函数可以访问本对象实例所拥有的那份类成员变量的拷贝。(由此我们也就可以理解为什么同一个类的不同的对象实例所拥有的同名成员变量的值可以不同,但是它们所拥有的成员函数却是相同的)。这一切都是由编译器在编译的时候暗中进行的,并且是由c++语言标准所规定了的。问题是CreateWindow和CreateWindowEx函数都不支持这个要命的this指针!我当时也想去看看MFC的消息映射是怎么解决这个问题的,但是我发现MFC是采用了在源程序文件中使用大量的、全局的宏定义的办法,我觉得这显然违背了封装性的原则,加之这部分MFC的源代码比较复杂而且不容易移植。所以我没有借鉴MFC的解决方案。
    我采用了在我自己的窗口类中定义一个静态成员函数作为窗口处理过程并把它传给CreateWindow和CreateWindowEx函数的办法来解决问题。由于c++类的静态成员函数及变量是在程序编译的时候静态生成的(非静态成员函数及变量都是在程序运行中随着类对象实例化的过程而动态产生的),其时类对象尚未建立,所以编译器不会给它们传递一个this指针。经过了这样的改进,我的窗口类终于可以通过编译这一关了。但是新的问题又产生了,我的这个静态的窗口过程函数不能调用窗口类里面的其他非静态的成员函数及变量!它只能访问静态的成员函数及变量。当然这也是合乎逻辑的,因为它没有自动地获得this指针,故不知道需要访问的非静态成员函数及变量的地址,自然就不容许进行这样的调用了。
    为了解决这个新的问题,我又在自己的窗口类里面声明了一个静态的成员变量专门用于保存本对象实例的this指针,由于静态成员变量也是在程序编译的时候静态生成的,所以静态成员函数可以很自然地访问它。我在自己的窗口类的构造函数里面把this指针赋给这个静态成员变量,然后在我的静态窗口处理函数里面通过这个this指针来访问我的窗口类里面的一个虚成员函数,由该虚成员函数来最终实现windows消息处理和解析(派遣)的工作。当我需要在派生类中进行消息处理的时候,我只需要重载这个虚成员函数就行了。这个解决方案看上去似乎已经很好了,但是却还存在着一个严重的缺陷!
    因为我是在我的窗口类的一个静态成员变量中存放类对象实例的this指针的,而在c++语言中静态成员变量又是由同一个类的所有对象实例共享的。所以,当我在程序中用这个窗口类同时实例化几个对象以便同时创建几个窗口(类似于MFC的多文档视程序)的时候,只有最后那个对象的this指针会被保留在该类的静态成员变量中,结果只有最后创建的那个窗口的窗口处理过程能得到正确的运行。这个Bug困恼了我很久,因为我刚开始的时候根本就没有想到过这个问题,我自以为我的窗口类已经很好了,所以当我的类在多窗口的应用中出现问题的时候,我不知所措,甚至于无从下手。
    当我查出这个Bug的时候,已经是很久以后的事情了,而且我已经逐渐接受了MFC了。我采取的解决方案是,在我的窗口类对象的成员函数调用CreateWindow或者CreateWindowEx函数创建窗口的时候,把本对象实例的this指针作为lparam参数传递给CreateWindow或者CreateWindowEx函数,然后在我的静态窗口处理过程函数中检测WM_NCCREATE消息,从该消息所附带的lparam参数中获取各对象实例的this指针,并且创建一个链表把这些this指针和相应的窗口句柄都保存起来。这样我就可以在我的静态窗口处理过程函数中通过检索链表获得访问各对象实例自己的窗口处理虚成员函数的指针了。解决了这个问题之后,我的确狂喜了一阵子,我终于可以通过虚函数重载的方法来实现windows消息的分级处理了!
    但是在以后的使用过程中,我发现我的这个解决方案的运行效率远不如MFC的消息映射的效率高,并且我直到现在都无法克服这个效率问题。我始终认为程序的运行效率是第一位的要素,并且我那时已经从心理和感情上接受MFC了。加之自己作类库实在是太难,我只是刚刚开始就碰到了这么一连串的麻烦,往往是刚解决一个问题就又引发了另一个新的问题,还来不及享受一下成功的感觉就得为新麻烦头痛,即便是最终解决了所有的问题又能怎么样呢?还是没有人家微软的MFC做得好!我们何必去做这种吃力不讨好的事情呢?!所以,我最终还是放弃了我已经编写完成了的那些类库的源代码,全面地投入了MFC的怀抱。现在,我描述问题和解决问题的时候都已经习惯于使用MFC的方法和思想了,原来那些习惯了的API函数反而生疏了。今天看到你的帖子里面提出了让我们自己作消息映射的动议,回想起当初自己作类库的冲动,不禁感慨万千,愿与君共勉之!

28 楼

x_uy_u_n :
          我对你的表现很失望啊!我还记得你在论述你的观点“算法对程序的执行效率的影响更大”的时候,举了一个关于冒泡排序和快速排序的例子。这给我留下了很深的映象,如果你能在你后续的帖子中都象这样以编程技术方面的事实和经验为支持自己观点的依据,那么我们大家特别是初学者都能从你的帖子中受益。可是你在后续的发言中却丢弃了这一优点,显得非常的急躁和主观。
    比如在前述关于_closure这个函数调用规范的问题上,你说VC6不支持而BCB支持。我随后进行了实验,并向你详细地列举了VC5(我这里只有VC5故不能作进一步的实验)所支持的那些函数调用规范,还给你详细解释了VC5默认的函数调用规范_decl,我记得最后还提醒了你使用陌生的函数调用规范可能会导致的兼容性问题。我本希望你能在回帖中详细说明你坚持要使用_closure这个函数调用规范的理由以及该规范的定义和优点。可是你是怎么做的?你既没有作进一步的研究,也没有去查任何资料,就立即给我回了帖。而你在回帖中用到的观点和逻辑是:你自己也不知道_closure这个关键字是什么意思(或者你根本就不想去了解它的作用),只是由于你在BCB的例程中看到了许多对_closure关键字的引用,所以你认为它非常有用,而既然VC不支持它,那就说明VC不如BCB!你用如此简单粗暴的主观性证据和逻辑怎么能说服我们大家,又怎能不让我失望?更主要的是你自己怎么能得到提高?在我看来,坚持使用自己不了解的并且可能导致潜在兼容性问题的东西,已经不只是固执了,而应该是偏执啊。
    再比如,我在告诉你使用BCB不能编写windows下的硬件设备驱动程序的时候,我已经翻阅了许多这方面的书,并且在网上查了许多的资料。我所获得的资料里面在谈到开发这类设备驱动程序的时候应该必备的开发工具的时候都提到需要:微软的DDK(设备驱动程序开发包)、微软的Visual Studio、其他第三方的调试工具等(比如SoftIce)。进一步的研究发现导致这个问题的原因是在于,作这个东西必须使用DDK,而没有类似MFC的类库可用。而微软DDK默认的开发平台是Visual Studio,使用象BCB那样的别的开发工具没有办法同DDK联结起来。我本希望你能找到运用BCB开发硬件设备驱动程序的途径,比如说应该如何对BCB的编译器和链接器进行设置以便把BCB和DDK成功地对接起来。如果你真的这么作了,那么不但我和其他的初学者可以大长见识,你自己的业务水平也可以得到提高啊!可是,你又一次让我的希望落空了。你的回帖中说,由于VC中有的语句和函数在BCB里面都有,并且在BCB里面也可以调用汇编语言程序,所以用BCB也可以写硬件设备驱动程序。事情真的象你说的这么简单吗?据我所知,开发设备驱动程序的编译器不但要能同DDK进行对接,而且由于设备驱动程序的二进制模块的文件格式与我们一般的动态链接库及可执行文件的二进制格式都不相同,所以编译器还要能够支持把源代码编译、链接生成这种特殊的格式才行。至于你说的在BCB中通过调用内嵌的汇编指令来写驱动程序,那也得先解决编译器同DDK的对接问题,并且要BCB的编译器支持设备驱动程序模块的特殊文件格式才行啊!更何况微软公司早已经不提倡在设备驱动程序中直接使用内嵌的汇编指令了,由于汇编指令的硬件依赖性太强,往往导致作出来的东西兼容性和可移植性不高,所以微软公司在其NT内核中提出了微驱动模型的概念,用户可以在设备驱动程序中使用C语言的指令直接调用系统服务。
    最后你曾经提出了一个用BCB编写的自动控制系统方面的例子来说明用BCB可以做硬件方面的东西。可是你是否知道在这类应用中其实并不一定需要象你所想象的那样同硬件进行亲密的接触。我自己就恰好作过这方面的工作,所以我知道现在市场上就有很多比较成熟的与PC机配套的A/D和D/A设备。这类设备往往都自带了在windows下的设备驱动程序和应用开发例程及文档。在作自动控制应用的时候,我们的工作往往只是通过A/D设备的驱动程序所提供的接口实时地获取由现场传感器传来的被控制对象和现场的信号,然后通过某种算法实时地计算出相应的控制量,再通过D/A设备的驱动程序所提供的接口把控制量实时地转换成控制信号传递给控制机构,由此完成一个控制环路。借助于现成的设备驱动程序我们基本上不必对硬件进行特别的编程。所以不但可以用BCB做,也完全可以用其他的工具如Dephi、VB之类的来做。

29 楼

我觉得自己太偏激了,几天都不好意思来论坛上转.

我的看法是VC是很强,我认识的强人都是VC的,DELPHI或者BCB的我只是知道而不认识.我自己说过"来VC的论坛说VC的不好无疑是送死."我又为自己表现的偏激感到愧疚,种种使我压力很大.
但是我有话还是想说,大家觉得有没有道理可以发表自己的见解.
iron兄说我根据__closure说VC不如BCB,没有吧?我只是说__closure的区别只是VC那时候考虑不周的一个因素.VC的框架不如BCB(我不是说这句说话的第一人.大家可以去网上看看客观而且权威点的分析.),那样很自然而且很应该啊,BCB比VC要出得迟,毕竟有VC作参考了,思路自然要广VC存在的问题BCB就可以想办法避免了(至于是不是带来另外的问题,我也不知道了.).MS的人很强,BORLAND的人也不是吃素的.

至于后来说DDK的问题的时候我承认是我的错误.我信服但是不完全.可能是大家对问题的理解不同.因为我觉得那样的论据像我之前说过的"VC不能使用www.link-rank.com里面的VCL-SKINS"一样.iron兄你都会说是"windows下的硬件设备驱动程序"需要"微软的DDK(设备驱动程序开发包)、微软的Visual Studio、其他第三方的调试工具等(比如SoftIce)。"我不是说过那样专用的东西要除外吗?不然怎么有个比较的准则?
我常常看到VC强人说熟练运用VC开发的效率也很高.的确真有其事.但是别忘记了前提是VC熟练的人.强人说自己搞了很多个类之后使用起来很方便.....别忘了成为VC强人的那个艰难的过程(相对DELPHI,BCB).学DELPHI的陈经韬从接触电脑到写出"黑洞"的时间不到一年.他写一个自动下载并可以配置EXE的程序一个晚上....强人写得快那是自然的.也说说我这个不强的人,我写一个屏幕传输SDK的(Lz77压缩比较变化部分传输),也是两三个小时.发送的部分我写了几个API的类不用什么功夫,主要是接收那个界面接口BCB做起来很方便,所见即所得......VC强人A写了一个很方便类,VC强人B也写了一个很方便的类,...纵使能比BCB的方便而且更加好,但是却不能成为标准,起码就没有发布语言本身的公司推广和支持(至少现在是这样).用A的作标准还是B的做标准?数不清的VC强人啊.能去方便刚搞VC的人能用上吗?

我很偏激的另一个原因是因为我知道全国用VC的人很多.那样应该很牛了吧?但是我们的软件业不及印度,那篇关于印度软件和我国软件的比较的文章不知道大家没有看过.比较长,我记得不清楚了,我的看法就是两个字----灵活(一百个人看<<红楼梦>>还一百种感想呢).是不是写程序一定要用VC?是不是写程序一定要使用链表而不能使用数组?
我没有说过VC不强,也不敢说,我还怕我的VC强朋友K我.但是我觉得使用BCB或者DELPHI这类的更加适合更多的人.楼主引用"bitfan"的贴子我觉得很有道理,说得很详细了."既然费尽心机地用VC做出来的东西还不如另一个学了Delphi3个月作出来的东西,我为什么一定要哪壶不开提哪壶?".
有多少人甚至是公司真的需要精确到那几毫秒的效率?现在的电脑的性能在不断提高呢.Visual C++的原意难道是越Visual越有错?BCB和DELPHI所见即所得的做法与Visual相悖?
以后我可能不会再回应,也没有必要争论,都是工具罢了,不是说一定要搞VC的才是强人,一定要VC才能写出程序来.
选合适自己的工具!我在这里发了这么多贴子就是为了说这个.
最后感谢wx兄的大气量和iron兄不厌其烦地说明,我受益非浅.

30 楼

iron老兄:
关于DDK的事我晚上和朋友说了一下,那个朋友说可以,
"可以..
DDK是c语言就可以啦.
只要是windows下的开发平台, 都是可以的."
"DDK和DIRECTX这些都一样..
MS当然希望越多平台可以用越好..."

我也不知道了,看OpenGL的教程的时候,有句说明OpenGL的接口是C,可以在任何C的32位WINDOWS编译器里面使用.后来我发现,不但BCB可以用OpenGL,DELPHI也可以使用,也见到DELPHI搞的D3D程序.
对DDK我不熟悉,是不是只能真的在VC下面使用啊?

我来回复

您尚未登录,请登录后再回复。点此登录或注册