VC++ 不如 Delphi 之我见

[haoel]

为什么会有很多喜欢用VC++的程序员呢？我不明白。
我认为VC++一点也不如Delphi，原因如下：

1、VC太过坚涩，不如Delphi易用。
如果一个程序没有易用性，那还怎么开发别的程序呢？比如：为了查找一个类的方
法，我得去找它的父类。拷，找来找去，还是没找到。还有，用VC编程给我的感觉就是
消息传来传去，哎，太不方便了。用VC和用delphi，就好像用DOS和Windows来操作系统。

2、VC开发程序的周期性太长，不如Delphi。
一个VC的程序用Delphi来做，周期至少减少一半。我有个同学用VC做了一年的程序，被我用Delphi两天就搞定了。再比如：为了读取一个BMP图片，Delphi中什么程序
也不用编，而VC呢？对于16bit的BMP和24bit的BMP要分别写程序。

3、VC编译效率太差，不如Delphi好。
一个VC的程序编译过程要花5——10分钟，甚至更长，最后等到的也许只是少个分
号。这点不如Delphi，Delphi编译一个程不会超过2分钟，而且EXE文件长度极小。而且，
如果你不用Win98 第二版（2222）做VC的OS，我相信，你一定经历过很多“非法操作”
吧，你还发现你没保存你的程序，是不是很过瘾哦？

4、帮助文件，VC不如Delphi的易读。
试想，一个如的编程语言，对程序员来说最重要的是联机帮助！这点我认为做得最
好的是PB，其次是VB和Delphi，VC的帮助嘛，在下实在不敢恭维，几百兆的HELP放在硬
盘上，没用。

5、任何用VC可以编程出的程序，Delphi都可以做。
都是Windows编程，都用Windows API，所有VC的程序Delphi都可以做，什么COM/DCOM、ActiveX、控制面板的程序、CGI、ISAPI、Winsock……，两者都可以做。
而且Delphi做得还要比VC好，比VC快。

6、Delphi可以编程有关MIS的程序，VC可以吗？
有关数据库程序的强力编程语言，我想非PB莫属，Delphi可以和PB一拼，VC呢？
真是相形见拙了。

7、Delphi有大量的VCL控件，而VC呢？
我认为，人类之所以发展，是因为，他能总结前人的经验。如果，一件事被人做过
了，我还有必要再去做一遍吗？老古人说：“吃生东西会拉肚子”，我还要去试验一下
吗？这里Delphi有大量的VCL控件可以使用，这不就是Delphi的亮点吗？Windows这所
以比别的操作系统更好，是因为它有大量的第三方软件的支持。Delphi同样也有大量的
第三方控件的支持，VC为什么没有呢？这对一个开发软件，对于一个程序员，是不是要
比VC有更强的生命力呢？试想，你的一个软件中有来自全世界的代码，这不正是现代的
编程观点吗？让资源共享起来不正是大家所需要的吗？

8、Delphi有For Linux的版本了，VC也有C#了。
可是VC还是只能在Windows上运行，这就是MS，完全抵制除了Windows外的OS，这
是发展之道吗？拷！！

——————————————————————————————————————
综上所述，这就是VC不如Delphi的原因了，在此发表，希望和大家一起讨论。
由于时间关系，还有很多VC不如Delphi的地方，我没有说出，欢迎大家指正。
我希望大家用事实来讲话，而不是用自已的感情。所谓事实胜于雄辩。你们看好吗？

[SoftDIY]

这么厉害，我是说顶楼开贴的仁兄，以后我问问题来delphi板好否，现在600分的问题还无人回答呢；你就以delphi怎么做回答一下:

VC不能RAD吗，你说的Delphi控件又有几个在codeguru找不到相应的源代码；

再看看经典的软件，acdsee、winzip、ultraedit、cuteftp、新贵imarkup、icq等等不都是VC编的，zdnet五星级中delphi编的必远少于VC，你不会说全世界的delphier都像你一样没创意吧，因为Delphi比VC强很多嘛，如果真是这样，你们Delphier就应该想想为什么创意没有VC程序员多：是不是用控件搭积木多了，束缚了自己的思维

[Benni]

我想说两件事。1：最近因为需要转到UNIX/LINUX下作开发，因为我是VC程序员，所以尽管我以前没有在UNIX/LINX作过开发，但我只花了半天就可以开始工作了，而Delphier,你们需要多长时间呢？2，要知道UNIX下好象还没有商业开发的PASICAL/DELPHI环境。我在UNIX/LINUX下编写了一个具有很强逻辑性的C功能函数，但是不正确，结果我把它嵌入到VC程序中，单步调试，哪里出错，很快发现，请问Delphi大虾们，你们是不是可以让Delphi单步调试C函数呢，Delphi可是无所不能的呀，大不了象haoel大虾抽出几秒，几分，点几下鼠标，拉几个控件，作一个C语言解释运行器不就解决了。我等待这样的调试器出现。

[ilovevc]

-----------Delphi vs VC---------------------------
1、VC太过坚涩，不如Delphi易用。
这是一个不同的开发类型,如果你没有使用VC超过一年以上，你根本就不是一个VC程序员，你也几乎无法用VC下开发任何程序，如果你使用Delphi超过10天，你可能可以用Delphi开发一个程序。当你使用C++就久，你就会越喜欢C，感觉是一种艺术。
而且你如果会VC，使用Delphi只是一个简单的适用过程。举个简单的例子，我不需要熟悉Delphi的TBrush类，我也可以在Delphi中创建Brush，我可以用我熟悉的API，如CreateBrush等，而如果你会Deplhi，你就必须研究Delphi中TBrush的源程序才能在VC或者VB，PB环境下使用Brush，而且API的语法是C格式的。
在普通的Delphi程序员和高级的Delphi程序员中区别没有普通的VC程序员和高级的VC程序员差别大，普通的VC程序员几乎无法写出一个商业级别的程序，而普通的Delphi程序员在某些场合（特指某些场合）写出的程序与高级的Delphi程序员差别不大。

2、VC开发程序的周期性太长，不如Delphi。
同样的原因,如果你只是做含有大量的Dialog的程序,Delphi也许更快，如果你的程序含有很多的数据结构，如果用MFC的话，模板和CList，CMap，CArray会使你收益很多，而Delphi中简单的TList是无法实现某些功能的。举个简单的例子，如果你需要实现打印御览，用VC绝对比Delphi要快和要容易实现得多。
而且你说的图像问题，好像LoadImage可以实现，不过因为你是Delphi程序员，可以原谅。

3、VC编译效率太差，不如Delphi好。
关于编译速度,VC(特别是MFC)在第一次编译的时候确实会需要很长的时间,以后可能差不多。我发现很多Delphi程序员喜欢提高这一点，对于编译速度我觉得没有太大的必要，执行的速度才是最重要的。如果你熟悉Delphi的语法（所有的变量定义必须放在函数的头部），你可能会理解pascal编译器的编译速度可能会快的原因。因为Delphi对语法的规定比C要严格得多。
关于“非法操作”的概率，如果你在VC和Delphi中写过程序的话，你会知道VC的开发环境要比Delphi稳定的多。Delphi编写大型软件时死机的频率很高。

[ilovevc]

-----------Delphi vs VC---------------------------
1、VC太过坚涩，不如Delphi易用。
这是一个不同的开发类型,如果你没有使用VC超过一年以上，你根本就不是一个VC程序员，你也几乎无法用VC下开发任何程序，如果你使用Delphi超过10天，你可能可以用Delphi开发一个程序。当你使用C++就久，你就会越喜欢C，感觉是一种艺术。
而且你如果会VC，使用Delphi只是一个简单的适用过程。举个简单的例子，我不需要熟悉Delphi的TBrush类，我也可以在Delphi中创建Brush，我可以用我熟悉的API，如CreateBrush等，而如果你会Deplhi，你就必须研究Delphi中TBrush的源程序才能在VC或者VB，PB环境下使用Brush，而且API的语法是C格式的。
在普通的Delphi程序员和高级的Delphi程序员中区别没有普通的VC程序员和高级的VC程序员差别大，普通的VC程序员几乎无法写出一个商业级别的程序，而普通的Delphi程序员在某些场合（特指某些场合）写出的程序与高级的Delphi程序员差别不大。

2、VC开发程序的周期性太长，不如Delphi。
同样的原因,如果你只是做含有大量的Dialog的程序,Delphi也许更快，如果你的程序含有很多的数据结构，如果用MFC的话，模板和CList，CMap，CArray会使你收益很多，而Delphi中简单的TList是无法实现某些功能的。举个简单的例子，如果你需要实现打印御览，用VC绝对比Delphi要快和要容易实现得多。
而且你说的图像问题，好像LoadImage可以实现，不过因为你是Delphi程序员，可以原谅。

3、VC编译效率太差，不如Delphi好。
关于编译速度,VC(特别是MFC)在第一次编译的时候确实会需要很长的时间,以后可能差不多。我发现很多Delphi程序员喜欢提高这一点，对于编译速度我觉得没有太大的必要，执行的速度才是最重要的。如果你熟悉Delphi的语法（所有的变量定义必须放在函数的头部），你可能会理解pascal编译器的编译速度可能会快的原因。因为Delphi对语法的规定比C要严格得多。
关于“非法操作”的概率，如果你在VC和Delphi中写过程序的话，你会知道VC的开发环境要比Delphi稳定的多。Delphi编写大型软件时死机的频率很高。

4、帮助文件，VC不如Delphi的易读。
这是个笑话。没有人说MSDN不是开发人员最好的帮助。Delphi的帮助只是很老式的帮助系统（那也叫帮助？？）。举个例子，如果你想知道哪个函数可以在Taskbar中添加一个Icon及它的语法，在Delphi中你必须知道这个函数叫Shell_NotifyIcon,在MSDN中查找Taskbar（Delphi的hlp文件可没有这个功能），马上就能知道这个API。更不用说关于TaskBar Icon的很多技术文章。


5、任何用VC可以编程出的程序，Delphi都可以做。
如果你涉及到较深的数据结构时，（不是那些对话框比较多的程序），可能需要多继承时，你会发现Delphi只是一种不完全的面向对象的语言，我现在还不明白在Delphi中一个子类中如何跨极来调用父类的虚拟成员函数。在VC中，假设CListBoxEx 继承CListBox，而CListBox 继承 CWnd，如果都有一个虚拟函数AssertValid，那么在CListBoxEx中可以通过类描述符（CWnd::AssertValid）来越过CListBox 的虚拟函数，而在Delphi中一个简单的inherited是会去调用CListBox的虚拟函数的。
另外一点是如果在Delphi中如果你想在一个数据结构中实现一个成员函数时，必须定义成class，而不是record，而Delphi的class是无法在栈中构造，必须显式的使用Create构造函数来分配内存，退出函数时又必须调用Free函数来释放内存，当程序中有多个出口时，简直就只能通过Goto语句来实现对象的释放。（VC的smart pointer就是利用了栈中对象自动释放的原理来避免了这种情况，也包括CWaitCursor类等）
好像Delphi只支持单继承。（这个应该没有写错）
据说DDK只能用C来开发。（不过我可没写过，也不确定）
VC是用VC开发的，同样，Delphi是用Delphi开发的，毫无疑问，VC的IDE比Delphi的要稳定，好用得多。


6、Delphi可以编程有关MIS的程序，VC可以吗？
几乎所有的数据库的底层都是用汇编和C写的，而且微软（如果是在Windows平台下的话）现在提出的OleDB技术（VB可能熟悉ADO）就几乎都是用C写的Com Dll。不过对于MIS这种需要大量的界面的程序来说，确实不是VC所擅长的。主要原因是找不到3个以上的VC高手，因为一般的VC程序员的编码效率可能是普通的Delphi程序员的10分之1，而高手之间的差别几乎相差无几。


7、Delphi有大量的VCL控件，而VC呢？
VB不也有大量的控件吗？只是绝大部分是用VC写的，而不是用Delphi，而且VCL只能在Delphi中使用，而OCX可以在几乎所用的Windows开发工具中使用（PB6.0除外，如果在控件的事件中含有一个对Variant的引用参数，PB无法使用这个事件，而且对Automation的支持简直是残不忍睹，现在的PB我不清楚。）只是VC程序员可能不太喜欢用控件，而喜欢用Class 或 Lib 一些。

8、Delphi有For Linux的版本了，VC也有C#了。
如果你需要编写Linux程序，一般是Server的程序，没有太多的界面元素，这就是C的优势，网络上大量的源程序都是用C写的。只要你熟悉C，你就可以拿来用。
并且Windows在个人操作系统中95%以上的占有率不值得也很少有需求为其他的操作系统编写客户端程序。

----------------------------------------------------------------------------------------
其他的优点：
9、更好的键盘支持。
在VC中写程序就好像在Delphi中写VCL一样，没有界面，只需要写代码。而在VC中所有的菜单命令都可以设置键盘的快捷键，对于一个不习惯用鼠标的程序员来说这确实是有一种行云流水的感觉。

10、宏和模板的功能
在C中支持的宏定义功能对编写和简化代码作了大量的工作。如MFC中的消息映射，IMPLEMENT_SERIAL等。模板类的支持也是一个。

11、更好的语言规范。
一般VC程序员都使用匈牙利命名法，而不是Delphi程序员使用的没有统一标准的变量命名。如在Delphi中有一个全局变量，一般很少加下划线或其他表识。包括Delphi源程序本身。（如Delphi中的EmptyParam等）。

12、Debug支持。
VC对调试有很好的支持，包括ASSERT，VERIFY，DEBUG_NEW等，对程序的方方面面进行诊断，使编写的程序更加稳定可靠。而Delphi虽然也提供了assert，但在Delhpi中用过的人知道它的功能确实有限，弹出一个对话框后程序继续运行，如果是在一个循环语句中有个assert语句，你可以只能重新起机才能避免Delphi弹出的成千上百个对话框让你一个一个的关闭。大量在VC中使用ASSERT宏的人调试程序时会知道那是多么大的帮助。
而且Delphi对内存泄漏一无所知，你只能自己留心内存的问题。
当程序是一个多线程的程序时，使用Delphi调试器引起死机那已经是一个家常便饭。

13、另外
Delphi开始的名称好像是VB Killer，确实VB和Delphi比确实远远不如，除了在Ole的支持比Delphi好以外，其他方面我看是确实VB能做到的（而且VB还需要外部控件）Delphi都能做到，包括界面的快速开发能力。

VC的名称有点名不符实，Visual体现太少。除了资源。特别是在Windows这种图形界面占很大比例的程序中,它提供的component还是一种代码插入的方式。我已经是VC的MCP，不过我对写Window的界面程序还是倾向于使用Delphi，Microsoft提供的Doc-View模式在很多情况下几乎无法派上用处。微软对VB的做法为什么不在VC中也得到一些体现，省得老要在CWnd::OnCreate中创建该死的ToolBar，Window等。

其实VC和Delphi在开发一个较大型程序时的时间相差无几，不过对VC一知半解的人几乎无法下手，而对Delphi一知半解的人比较容易上手罢了。

=---------------------------------------------------------------
程序员大本营连个会写ASP分页的人都找不到吗？？？
最新的贴子放在最下面，真搞笑。

[ilovevc]

-----------Delphi vs VC---------------------------
1、VC太过坚涩，不如Delphi易用。
这是一个不同的开发类型,如果你没有使用VC超过一年以上，你根本就不是一个VC程序员，你也几乎无法用VC下开发任何程序，如果你使用Delphi超过10天，你可能可以用Delphi开发一个程序。当你使用C++就久，你就会越喜欢C，感觉是一种艺术。
而且你如果会VC，使用Delphi只是一个简单的适用过程。举个简单的例子，我不需要熟悉Delphi的TBrush类，我也可以在Delphi中创建Brush，我可以用我熟悉的API，如CreateBrush等，而如果你会Deplhi，你就必须研究Delphi中TBrush的源程序才能在VC或者VB，PB环境下使用Brush，而且API的语法是C格式的。
在普通的Delphi程序员和高级的Delphi程序员中区别没有普通的VC程序员和高级的VC程序员差别大，普通的VC程序员几乎无法写出一个商业级别的程序，而普通的Delphi程序员在某些场合（特指某些场合）写出的程序与高级的Delphi程序员差别不大。

[shines77]

咦？怎么没人说话了？我来说两句，
我是VB底手，对VC++一点都不熟，对Delphi吗也狗屁不通，我就纳闷，你们在这狗咬狗 那是为何，其实我告诉你 编程的语言我没一个是满意的 包括BCB，甭以为VC++就酷到哪了，Delphi又如何如何了，我告你，其实哪一个都很白痴，你们还是想想怎么做一个全能一点的编程语音，甭管什么语音都能用，什么都支持，理论上是成立的，我看你们还争什么争，我看你们还是老老实实，踏踏实实，努努力力的把我们的中国软件做好，不要让外国人来耻笑我们（幸好我不是外国佬：），好了。
说句实话，Borland的VCL是不错的东西，VC++早该学过去了，奇怪的是没有，可能是怕Borland说他，是我才不怕呢，Delphi不是学Visual系列的吗，VCL的效率低于VC++的类，但高于Ocx控件，闪光点是可以打进exe(很酷)，另外澄清一点VCL应该称为构件，而不是控件，是跟Ocx控件相区别的。
好了，我也说了这么多废话，好像觉得还不过瘾（突然发现有一不明飞行物飞过来，正中……，^％！％^￥@^！，我的脑袋）。
希望大家多多努力，把我们中国自己的语言早日做出来，就不用在这里争美国的女人波大还是日本女人的奶子爽，好自为之吧。希望她的名字有点中国味，就叫“MdM”吧（美达美？妹妹？美眉？），不得而知，本人跟MdM没有任何关系哦，是吗，zdg 哈哈：）
爽了一点了………………
谁能做一个世界上最酷的语言啊？哈…………蛤…………？？
加油哦，兄弟们

[shines77]

APIer说得很对，其实我也用很多的API，当你用API来编程的时候，你就会觉得哪种语言都一样，就像到了联合国似的，讲国际语一样，没有什么语言的差别。试问，Delphi，VC++，BCB哪个不是调用API的，那不就是一样的吗，哪有什么孰优孰劣的想法。编程当中不掌握一些API，是做不好程序的，相对来说MFC封装API比较好一些，但VCL也相当的酷，因为他的源代码是透明的。补充一句，即使是VB，你掌握了一些API，做程序也很酷，当然这些API很多是从VCL和其他地方看来的，
还有，VB也可以做Subclassing(子类处理)，也并不难，你能做的，VB也能做，这样看来，你们还会对 Delphi Vs VC++ 感兴趣吗？？哈哈

[shines77]

APIer说得很对，其实我也用很多的API，当你用API来编程的时候，你就会觉得哪种语言都一样，就像到了联合国似的，讲国际语一样，没有什么语言的差别。试问，Delphi，VC++，BCB哪个不是调用API的，那不就是一样的吗，哪有什么孰优孰劣的想法。编程当中不掌握一些API，是做不好程序的，相对来说MFC封装API比较好一些，但VCL也相当的酷，因为他的源代码是透明的。补充一句，即使是VB，你掌握了一些API，做程序也很酷，当然这些API很多是从VCL和其他地方看来的，
还有，VB也可以做Subclassing(子类处理)，也并不难，回调函数也可以做到，就是指针的概念模糊一点，但也很简单就解决，你能做的，VB也能做，这样看来，你们还会对 Delphi Vs VC++ 感兴趣吗？？哈哈

[ilovevc]

re JackII:

//ilovevc,你说的话使我有点不明白了，你编写程序的目的难道是为了表示你比别人高吗？
我没有这个意思。

//你难道不认为这正是Dephi的优点吗？
//而你认为真正的Dephi高手他写的程序难道也只是摆摆控件吗？
你理解错了。我通篇的意思都认为Delphi高手和VC高手一样。我敬佩所有的高手。包括VB,PB等。

//你认为Delphi不是一个完全的面向对象语言，能不能问你一下你的标准是什么？
//难道只因为Delphi不能够多重继承？我想这个连世界上都没有争论结果的问题，我们就不要在
//这里提吧！
我以C++的观点。多态，继承，分装。

//至于你说的Delphi的程序员要在VC或者VB、PB环境下使用Brush就必须研究Delphi中TBrush
//的源程序，我想这不用吧，你不觉得Delphi是个很好学习API的工具的吗？
我说的没错。就是说要看Delphi提供的源码研究api，因为在其他环境中没有TBrush类。如果不用看它的源码，你如何创建Brush???你如何得知CreateBrush这个api函数？？？

//如果你用VC只是局限于MFC的话，我想你还不是个合格的vc程序员，
是不是不用你说。

//何况MFC好像并不提供原码。
MFC提供源码。

//delphi的道理是一样的
Delphi也提供它的源码，当然我说的不是Delphi程序本身的源码。而是Delphi封装的类的源码。

-----------------------------------------------------------
还有我的回答。
//现在的问题是如果脱离了windows环境，vc的程序员们会怎么样？
至少比Delphi要过的好。

//如果，作为一个程序员，你真的认为vc很重要吗?
无所谓

[APIer]

breath:
我这一段时间一直关注着这个问题的讨论，今天看到你的新帖子，觉得讲得很
公道，很有道理，希望和你交流，向你学习！
我不会PASCAL，所以没用过DELPHI，我只用VC和BCB，BCB也是用的VCL，我觉得
VCL的确是很优秀，至少比MFC好用，易用。BORLAND的可视化技术我觉得要比MS好
但是，要说DELPHI比VC好，我看也未必，看完上面一些DELPHI高手的帖子，我真的
很佩服他们对程序编写的理解，但我不知道他们的这些高深的知识是通过学DEIPHI
学的吗？我看他们都象是优秀的C程序员啊！我想一些深奥的东东，他们大概也是
在C的学习过程中领会的吧！C的强大是无可质疑的。
我认识一些人，他们用VB写出了很多漂亮的程序，并沾沾自喜，当打开工程文
件时，我却发现，他们写的代码不到100行，凭这100行代码，他们就理解了MP3的
解压了吗？不是，那只是一些皮毛啊！不错，利用现成的控件是个很好很好很好的
习惯。但是大家都来利用现成的东东，谁来写控件？你用控件写出来的MP3播放器
有多少价值？
我讲这些并不是说DELPHI写不出好东东来，而是不管用什么语言，了解他的工
作机理才能写出精品软件来的，FOXMAIL是DELPHI写的，但他的POP3和SMTP是用什
么控件写的？不是控件是用的API！VCL里有POP3和SMTP控件，不知道用这个写出
的FOXMAIL有没有人用？你再有创意，控件不支持，有用吗？
利用一些现成的控件开发软件的确很容易满足程序员急于看到成绩的心理。
但是当你回头想一想你自己到底写了什么时，可能你自己都觉得没意思了，反正我
开始学VB，两天自己就写了一个游戏管理器，很了不起的给同学看，但同学要看我
的源代码时，我自己都脸红了，因为我实在是没干什么事情。当时我虽然写出了程
序，我就是程序员了吗？不是，我当时连WINDOWS的消息循环是什么都不知道！后
来我终于丢掉了VB，开始学VC，而且是SDK编程。在SDK学习中我才知道了以前用的
一些控件实际的工作原理，后来我反过来学BCB的VCL时，这些知识给了我很大的
帮助。
还有用DELPHI写一个图片浏览工具很简单，放几个控件，写几行代码控制图片
来源，显示位置就可以了，但是，先不说这个图象浏览器有没有实际价值，就说如
果你要写游戏，要操作Direct表面，你就会发现那些所谓的图象操作都是没用的，
你还是必须了解图片的文件结构，方正光是位图的数据结构就搞得我这菜鸟够呛。
更不要说JPEG之类的东东。所以，遍程序并不等于堆控件，理解程序的实际运行机
制才是开启程序大门的钥匙！不管他是用的什么编译器。
当然，我并不是反对使用控件来节约编程时间，我自己就使用BCB比VC多得多，
关键是对程序的理解要深一点（这点我是还很不够的，希望各路神仙多多指教）！
关于VC和DELPHI谁优谁劣，我觉得因该更多的去考虑他们的编译速度，代码质量
等等，而不是RAD和普通开发环境只争。毕竟两者不是同一类型的东西嘛。说到编译
质量，我曾用BCB写过一个全API的窗口程序才40K，而VC写的有100K左右，不知道
这能不能说明宝蓝的编译器要好一点呢？
我把自己的观点总结一下，从易用性来讲DELPHI肯定要比VC好很多，至于DELPHI
能做VC所有的事如果是事实的话（不知道和VC做是不是一样做的好，而且更容易），
我想DILPHI用户大可狠钻DELPHI，但也完全没必要去说VC不行，毕竟不到了深层次的
软件开发，VC和DELPHI都是殊途同归了，DELPHI是要推广，但VC我们还是要鼓励有
兴趣的人去学习使用的！总不能全国的程序员都在用DELPHI，没有一个C程序员吧！
如果真的DELPHI可以完全取代VC，那VC根本就没必要出新版本了，对吗？
以上是个人观点，欢迎讨论！谢谢！

[breath]

回答APIer:
是的，我也喜欢交朋友，包括JackII，无论用VC还是Delphi，我们不都是为了一个理想走到一起的么？那就是成为开发软件的大师。我们也是为了一个目的来到这里，那就是提高自我，相互促进，为中国软件尽一分力（我的狭隘的爱国主义）。
92年我开始入哈尔滨建筑大学计算机系学习。认识我们从89到96届几乎所有的出类拔萃的同学（当然，哈建大计算机系不能与清华工大等学校相比，但是我们也都在奋斗）。今年我27，
我想说：经过这么多年，我仍然坚持软件开发，这几乎是一种悲壮的情结在支持着我。在这8年中，我看到无数自称高手或者就是高手的人转行了，他们仍然在计算机的圈子里，可能是做了业务主管，销售代表或者什么机关的计算机负责人等等。而我们的IT界如此落伍，不断的用品牌和广告欺骗老百姓，这与搞开发的人少是否有关？...我毕业后去了黑龙江省建筑设计院，那里可以说是相当理想的工作地方，每天维护计算机即可，而且上网免费，工资待遇优厚，奖金更是没的说。可那里是建筑师的乐园，同为年轻人的我没有什么重要事可做。我那时就想，早知今日，何必当初呢？（在学校时曾经下课就去机房赖机器，用汇编做五子棋，用TC做256色的小游戏，为了制作工程软件旷课被处分等），现在我的存在有谁认可呢？我终于辞职了，暂时不想离开北方，现在在做工程软件，共享软件，这时我才发现，我浪费的时间太多了，而我编写的有用的代码太少了。而许多知识，我已经落后了。这也是我常来VC网站吸收营养的目的。
离开设计院，一切要靠自己了，可是我终于圆了自己当初的梦想，随心所意的创作、制作。虽然大多数时候是在为生计制作工程软件。哈尔滨建筑大学舆哈尔滨工业大学合并之前（现在在合并中）我们计算机系的老师请我们还在哈尔滨以及能够回来的同学吃饭，我很自豪的对老师说，我现在仍然在编程序，在做开发（不是市场营销或者烧钱什么的，当然，也许我当初出去了，可能也这样了）。越说越跑题了。每个做开发的同行，你准备好坚持到底了么？每个新新开发人类，你几年后还能以开发为乐，为荣么？
这里，我敬所有的仍然在做开发的同行们一杯，你们应该牛。中国的希望靠你们了，而不是什么自称中国脊梁而其实是中国肋条的（少一根也没什么的那种）。
我想我们开发者的争论不要太针对个人的好。同为开发者，何必彼此难为呢？只是讨论就好。免得被一些傻×称我们为G咬G，有时间多回答一些问题，帮助一下实在找不到办法的同行。对于那些想偷懒的人的问题当然算了，曾经有人问我，VB下怎么用print做格式输出，我告诉他，你先看看书吧。（拜托，先化化妆再来好不好）
呵呵。
有骂我的用邮件吧，怪不好意思的。本来晚上起来随意走走，听到这里人声鼎沸就进来看一看，你让我说深一些，我...我牙齿还没有刷呢

[SoftDIY]

我怎么看不到最新的

[Michaelyfj]

我赞同

[lisicheng]

同意hpei的看法，但haoel能否拷一份C#给我，或告诉我哪儿能买到

[rainbow]

关注

[cqjiang]

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
你研究过MFC类库原代码吗？我觉得封装的相当科学，BCB中也完全照抄了VC50中MFC源代码。若要彻底搞清楚MFC,唯一的办法是认真阅读MFC的基本类库原码。所以不要说VC晦涩难懂，只是你的思路和MS有点不一样。我分析过国外站点上的原码，发现很多思路和我们不一样。
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

[wjf]

精彩！精彩！
VC,DELPHI各有所长。正所谓量体裁衣，因材施教，萝卜白菜各有所爱，没什么好争的。怎么方
便怎么用呗！

[yxwhrz]

用VC的朋友，请不要盲目地评论Delphi，用Delphi的朋友，请不要盲目的评论VC！
Delphi的Object Pascal是个与C及C++功能类似的编程语言，Delphi是用Pascal编写的，而非C或C++！其语法格式与C或C++不一样，但效率绝对不比C或C++低！另外，Delphi及BCB都很大度，其源代码（VCL）是公开的，编程人员可以很深入地学习！此外，据在下所知，Delphi是可以很方便地操纵底层硬件的，只是您要学会Pascal而已，编个Vxd也很容易！操纵数据库就不用说了，嵌入式SQL是有的（只要您稍微看一下就知！）对数据库的访问，对
控件的修改，编译效率都是不成问题的！各有所好，大家说话客气一点。但微软件的东西总体来说要大一点、慢一点，这是因其商业习惯所为！比如,OFFICE套件就很好，但其支持语言是VB！

[FBStudio]

我的“网上拱猪”1.1版都出来了，你们还在吵，有意思吗？
我喜欢用BCB和VC，想一想用{}就能替换begin和end，就不愿用DELPHI。
建议zdg关掉这个浪费了大家时间的无聊的主题，大家该干什么还干什么去吧.

[cheka]

关键是什么人写，怎么写，而不是拿什么写