那你的mfc库是动态连结还是静态连结?如果Release模式编译出来1.38Mb,肯定是加入了许多不需要的库。
解决方案 »
- MFC编程,新增一个对话框时,怎么传递一个整型参数给它?
- MFC中的定时器不能正常触发
- 如何让ListCtrl只显示文件图标或者缩略图,不让它显示文件名?
- 桌面画图问题
- 问一个关于视频采集的问题
- 如何在一个字符串中插入“”即双引号啊
- 菜鸟问题:如何实现,在打开一个记事本时弹出一个对话框?
- 在看windows网络程序设计电子书的英文版的时候,书中的代码中的一些字符显示不出来,是怎样造成的,如何解决?
- 在程序中如何实现分页打印?
- PushSourceBitmapSet-->AVI Mux-->File Writer,生成AVI不正常的问题?
- user breakpoint called from code at 0x77fdjkf,这是什么意思啊?
- 想在VC下开发SSL,为什么找不到schannel.h头文件?我该怎么办?
估计是库多余了:)
我以前遇到过:把图片加到资源里后1.33MB
最后把图片放在文件里调用,程序就101KB了
要不,你那1MB多的程序要多少行代码啊
其实很久以前我就想写这篇文章,其原因一方面是因为笔者深深感觉到C++ Builder的确是一个先进与强大的程式开发工具,但更最重要的一点是,我深信C++ Builder能给公司带来巨大了商业利益与生产力的大幅提升,我可以假装没看到这几点,但是基於良心与责任我不能不花点时间来跟大家分享一下我的看法与心得。 C++ Builder的前身是Borland C++,Borland C++ 所使用的 Application Framework是OWL,而OWL以物件导向的角度来看,也的确比MFC先进很多(这在学界早有定论),但是在市场上却叫好不叫座,直到Imprise(以前的Borland)推出以VCL为Application Framework的Delphi之後,这才一炮而红。 虽然Delphi的VCL非常强大与好用,但是Delphi所使用的是OOPascal语法,和C++不同,直到後来,Imprise才推出以C++为程式语言的C++ Builder,而其所使用的Application Framework正是赫赫有名的VCL。 VCL的全名是“Visual Component Library“,它是一种新一代的Application Framework,以元件化、视觉化为设计的方向。VCL的兴起,起源於OWL和MFC都日见庞大与痴肥,不利於日益复杂的程式开发趋势,於是Imprise的设计小组决定开发一套更物件导向化的Application Framework,使程式设计师能以视觉化的观念、元件重用的观念来快速设计出各式各样的应用程式,将物件导向的威力与精髓发挥的淋漓尽致,相形之下,OWL和MFC都只算过时与半子的Application Framework。 果然~C++ Builder一推出後,在微软的大军压境下以及人们西瓜靠大边的心态下,仍然引起了一阵旋风,在News上许多程式师表示它们对C++ Builder的肯定与激赏,更有人指出,根据经验,在微软的市场优势之下,Delphi和C++ Builder仍能欣欣向荣,这表示Delphi和C ++ Builder的产品水准不是只赢微软产品几个百分点,而是数十至数百个百分点,否则Imprise的产品早就消失不见了。 到底C++ Builder的特性与优点在哪里呢?这对於我们公司又有什麽利弊呢?我的观点与分析如下。大家想一想,当我们使用Visual C++来开发程式的时候,最痛苦的事情是什麽?答对了~那就是GUI的设计。根据经验,通常我们利用Visual C++开发一套软体时,设计GUI所花的时间几乎占掉程式开发周期的三分之一~甚至到二分之一以上,而设计和界面无关的核心程式通常只占了不到二分之一左右至三分之二的时间,但是使用C++ Builder则可以大幅简化这个问题。C++ Builder的VCL提供大量的各式各样GUI软体元件,让我们可以将大部分的心力放在核心程式码的设计上,而不必跟Windows系统的讯息、界面去搏斗。 C++ Builder的Compiler在功能上跟Visual C++都一样,Win32 API等都可以呼叫与使用(VCL就是架构在Win32 API之上,没有不相容的问题,只是包装的更高明,也非常有弹性),你不用担心目前有什麽事情是Visual C++可以做而C++ Builder做不到的,进而拒绝使用C++ Builder,抱持这样的观点就好像为了健康而不坐汽车,却坚持骑脚踏车从淡水来上班一样因噎废食,在网路许多非常有经验的程式设计师会告诉你这是多虑了。曾有人比喻的很传神,如果Visual C++是手排车,那C++ Builder就是手自排两用车(看过三菱的Sportsmode手自排两用车吗?)。 C++ Builder的程式设计细节是清楚而透明的,除了Application Framework的运作保有神秘感之外(MFC也是),所有的程式码与档案相关的档案都是可以掌握与观看的,不像某些开发工具,程式设计师许多事情是无法掌握的,而C++ Builder 所产生的码大小与产生的时间都和Visual C++ 都是同级的(我指的是胜负差距都不大,到要一提的是,C++ Builder 6.0采用一种技术,可以使得第二次以後的Compiling速度提升五倍以上,笔者可以证实这一点)。 我的观点是,我们公司非常适合大量采用C++Builder作为程式开发工具,当然啦,为了相容性的考量和母公司有特殊要求的专案除外。由Visual C++转换到C++ Builder不是很严重与痛苦的事情,反而会觉得很快乐,这就好像开手排车人改学自排车一样,甚至可以更掌握C++ Builder的威力。 利用C++ Builder来开发程式,我们可以快速的产生程式的GUI layout和prototype,在後续调整程式界面的调整周期中也非常的方便,我个人认为至少可以比
Visual C++节省三至五倍以上的时间。 除了某些特殊需求的专案之外(例如版本升级,而原来的版本是VC开发的,或者参考改写的程式码是用VC写的,事实上C++ Builder也可以支援MFC),我看不出来公司有什麽专案的规模或内容非要靠Visual C++不可,自己找罪受不说,也违反了“Build a high performance company“的目标,而将大量的资源投注在落後的工具上,程式生产力也无法巨幅提升。因此我建议公司应该大量而全面性的鼓励员工使用并熟悉C++ Builder成为第一线的程式开发工具,根据我的浅见,这样的投资不但回收快速,而且效果宏大。 简而言之,C++ Builder同时兼具C++程式语言的威力和Visual Basic这种 Rapid 不知道各位有什么看法?就开发COM和网络、以及分布式、多层数据库方面,VC++真是太罗嗦了!这也是一个方面!!
consider……
Release下编译339K,但是经过Winzip压缩后96K,还是有很多水分!!!谁有高见!!
Release下编译339K,但是经过Winzip压缩后96K,还是有很多水分!!!谁有高见!!
标等. 单纯代码的话编译出来是很少的. 另外假如连了大量不必要的
lib也会导致增加. 但一般增加不会太大,特别是release版.