想搞下上位机，麻烦大家推荐下用哪个软件比较好？是C++还是其他？

eagle2006 · 发表于 2007-10-19 21:22:19

想搞下上位机，麻烦大家推荐下用哪个软件比较好？

是C++还是其他？

hushaoxin · 发表于 2007-10-19 21:25:39

usbfish · 发表于 2007-10-19 21:27:47

Delphi

zxd0225 · 发表于 2007-10-19 21:55:12

C++ Builder

sdnr · 发表于 2007-10-19 23:01:35

从语言的能力讲，不推荐用VB和delph，但是这两个要相对容易一些。C++ Builder做界面不是太方便。如果在windows下，推荐用VC.

zxd0225 · 发表于 2007-10-20 00:00:08

C++ Builder做界面不是太方便?
是不是在开玩笑啊！！！！！！
C++ Builder做界面不知道比VC快了多少倍！
实际上按照语法的严谨程度讲，DELPHI的PASCAL语言比C++还要严谨。
我们搞电子的做下位机一般都用C语言了，如果搞上位机自然比较倾向于C++了。

avruser · 发表于 2007-10-20 00:07:00

5楼说的好！
4楼开玩笑呢吧？

usbfish · 发表于 2007-10-20 00:58:02

呵呵，上位机，我只用delphi和Vc
使用Vc仅仅是C语言的惯性，仅此而已，拿Vc作人机界面，那叫一个郁闷。

hl0716 · 发表于 2007-10-20 10:49:48

C++ Builder 方便

ilikemcu · 发表于 2007-10-20 10:57:31

没有好坏之分，只要能完成功能，顺手就行！

除非你是专业的上位机的开发工程师，业余级别的就不要去考虑那么多，好用方便稳定才是最先考虑的。

sdnr · 发表于 2007-10-20 15:52:39

很可能是一直用VC习惯了而已。delphi用过一段时间，觉得不顺手就懒得用了。个人看法而已，仅供参考。5楼的看来很强啊，各种语言和编译环境都精通。佩服啊。C++Builder这么好，我找时间也学习一下子。

YaoHui · 发表于 2007-10-20 16:08:40

我用python，脚本语言，跨平台，还能编译成EXE，就是生成的东西比较大。

sdnr · 发表于 2007-10-20 16:20:22

找到一篇文章，比较全面。转给楼主参考一下
"Visual C++与Delphi之比较"最近在CSDN的论坛上的讨论非常火热，本文将以一个程序员的角度，从技术水平、功能、性能、易用性、稳定性、发展历程和前景等方面，以Visual C++6和Delphi5为代表，尽可能客观地比较介绍Visual C++和Delphi这两大主流开发工具的优缺点，其中将涉及到语言、应用框架、控件、编译和连接、集成界面、调试、COM、数据库开发等。本文还将对如何选择使用这两个开发工具提出一些建议。

值得一提的是，由于C++Builder与Delphi同为Inprise公司产品，它们除了使用的语言不同，其余特性几乎都相同。因此本文对C++Builder程序员和学习者也有参考价值。

语言：存在即是合理

首先声明常被混淆的一点：VC和Delphi本身不是语言，而是开发平台。它们所用的语言分别是略作扩展的C/C++和Object Pascal。我在网上常看到有人问应该学C/C++还是VC，这个问题很好回答：如果你学VC你就必须得学C/C++，或者说你学会了VC也就学会了C/C++了。

言归正传，我们来比较一下C++和Object Pascal的优缺点。有人认为Object Pascal是"玩具语言"，C++才是"专业语言"，这是不对的。单从语言本身看，Object Pascal与C++属同一重量级。它们都是完全支持面向对象的语言，都扎根于"历史悠久"的面向过程的语言。C++是由C发展而来的，Object Pascal由Pascal进化而来。它们都有很强的灵活性，都有自己的特长和不足。比如说，Object Pascal不支持多重继承、模板、操作符重载、内联函数定义、预处理、宏、全局静态类变量、嵌套类定义，等等，而这些都是C++支持的。但同样地C++也不支持Object Pascal的虚构造函数、过程嵌套、内置集合类型、内置字符串类型、"finally"构造等等，在RTTI方面Object Pascal也比C++做得好。但这些并不重要，因为可以通过其它方式达到同样的目的，比如C++可以通过类扩展支持集合、字符串，Object Pascal可以通过"inte***ce"多重继承，等等。关键是二者都可以很好地完成你手头的任务，这就够了。

但是，仅仅比较语言本身是不够的，还得看它们的被接受和流行程度，学习曲线，发展前途，可移植性等，以及，很重要但常常被忽略的一点：与开发环境(指VC与Delphi)及其应用框架的"磨合"程度。

VC和Delphi作为开发平台，很重要的一点就是提供了一个"无所不包"的应用框架：VC的MFC和Delphi的VCL。MFC是用C++写的，VCL是用Object Pascal写的。当然，我们都知道，C++的使用范围比Object Pascal广得多，移植性也好得多。这本来是优点，但很有意思的是，正因为如此，微软写MFC时必须考虑最大限度减少对语言本身的改动，而把功夫下在源代码级，以便能尽可能支持ANSI等标准，结果导致MFC的封装复杂而不直观。(尤其是它对消息的封装，下文还会提到)。太多的宏定义和含义模糊且自动生成、不得改动的注释使MFC乃至VC让很多新手望而生畏，不敢"下水"深入学习。而Object Pascal几乎是Inprise"专用"的，不必考虑"标准"问题，因此Inprise写VCL时就把全部精力放在了结构与性能上，结果语言与框架的磨合程度非常好。VCL框架的结构清晰，VCL代码的可读性非常好。许多人说Delphi比较容易上手，也是这个缘故。天下没有白吃的午餐。你要工业标准吗？你要可移植性吗(关于可移植性和兼容性，下文会详细比较)？那么请面对MFC的"天书"级代码吧。

编译和连接：The Need For Speed

不同的语言带来的另一个不同是，编译和连接的速度的不同，以及执行速度的不同。Delphi的编译和连接速度，毫不夸张地说，比VC快几十倍。即使把VC的Incremental Link选项打开，Delphi的编译和连接速度仍比VC快好几倍。并不是说微软的编译器不行，这是由C++的复杂性决定的。模板的处理、预处理和宏的展开都是很费时的。前文不是提到Object Pascal没有模板、预处理和宏吗？这本来是缺点，但带来的一个好处就是编译速度极快。至于编译完的二进制代码，在打开相同的优化选项的情况下，Delphi和VC执行速度并没有太大的差别。

为了克服编译的速度问题，C++编译器一般需要增强的连接器和预处理机制。但是预处理机制仍然存在若干问题：1）程序调试的断点行可能和代码行不同；2）没有将最新的代码信息综合进去；3）容易产生错误的逻辑；4）因为读错文件头而很容易产生类似"Unexpected End of File"的错误。

两个编译器有个共同点是都能识别无用的"死"代码，比如一个没有用的函数等等。编译后的程序将不包含这些多余的信息。Delphi在这方面作得更加出色。它可以让你在编辑器中可视化地提示出那行代码是"活"的、那行代码是"死"的。这样你就能整理出最精简的代码。Delphi在编译后将在左边显示一个小蓝点表示这行代码是"活"的。Visual C++做不到这点。

Delphi编译后可执行文件至少有200K（如果不使用VCL，仅仅使用WinAPI，文件的大小将大大缩小）但是Visual C++编程使用MFC编译后的可执行文件通常只有几十K，主要是因为微软已经将系统运行库包含在Windows系统了（Borland公司曾经和微软协商这个接口，但是微软利用操作系统的优势不愿意公开）。同样道理，使用BDE开发的的数据库程序必须附带3-5M的额外系统文件，也是非常不协调的。

非常有趣的是，Delphi能够使用由C++ Builder创建的的OBJ文件，但是使用上受很大的局限性。

最后，Visual C++的编译和连接时的错误信息比Delphi要详细和具体的多。特别是使用ATL开发更加如此。

应用框架：MFC？有KFC流行吗？

应用程序框架(Application Frame)，有时也称为对象框架。Visual C++采用的框架是MFC。MFC不仅仅是人们通常理解的一个类库(同样，Delphi的VCL也不仅仅是一个控件库，尽管它的名字叫"可视控件库")。你如果选择了MFC，也就选择了一种程序结构，一种编程风格。MFC早在Windows 3.x的时代就出现了，那时的Visual C++还是16位的。经过这些年的不断补充和完善，MFC已经十分成熟。但由于原型出现得比较早，MFC相比于VCL落后了一个时代。尽管微软对MFC的更新没有停止，我也经常读到"只要Windows不过时，MFC就不会过时"之类观点的文章，但就象Inprise(原Borland)的OWL框架的淡出一样，MFC的淡出也是早晚的事。其实MFC是和OWL同一个时代的产物。OWL已经不在了，MFC怎能不"居安思危"呢？如果MFC青春永驻，微软的开发人员也不会"私自"开发出基于ATL的WTL呀。当然，WTL的地位不能和MFC比，它并不是微软官方支持的框架，封装的功能也相当有限。但至少也反衬出了MFC存在的不足。

我们以为，最能体现一个应用程序框架的先进性的是它的委托模型，即对Windows消息的封装机制。对Windows API的封装就不用说了吧。大同小异，也没什么技术含量。如果高兴，你也可以自己写一个类库来封装。但对Windows消息驱动机制的封装就不是那么容易的了。最自然的封装方式是采用虚成员函数。如果要响应某个消息就重载相应的虚函数。但出乎我的意料，MFC采用的是"古老"的宏定义方法。用宏定义方法的好处是省去了虚函数VTable的系统开销(由于Windows的消息种类很多，开销不算太小)。不过带来的缺点就是映射不太直观。对于MFC，则是"太不直观"了。它的消息映射代码虽然是可见的，但"劝君莫碰"。好在VC的ClassWizard可以自动生成消息映射代码，使用起来还算方便。但和VCL的委托模型相比，MFC的映射方法就显得太落后了。而Delphi的Object Pascal因为没有"标准负担"，语言引入了组件、事件处理、属性等新特性。由于功夫做在编译器级，生成的源代码就显得十分简洁。似乎VC是"让框架迁就语言"，而Delphi是"让语言迁就框架"。

我想举一个对字符串操作的封装的例子来说明MFC和VCL的优缺点。在MFC中，CStringList类有加入、获取、删除等功能，但VCL的TStringList类除了上述功能还有排序、从逗号分隔的字串读入、流输入输出等功能。但同样的字符串替换功能，VCL的StringReplace要比MFC的CString::Replace慢2－3倍。总的来说，VCL的封装比MFC更为高层，更为抽象，但不可避免地带来的问题是某些部分执行效率比MFC略低。这就象低级语言(如汇编)的执行效率比高级语言(如Basic)高，但编程效率较低。鱼和熊掌不可兼得嘛。

VCL比之MFC的另一优点是对异常处理的支持，而一大缺点是对多线程支持差。VCL的大部分都不是针对多线程优化的。虽说VCL提供了简化多线程操作的类，但只是工作者线程(worker threads)使用起来比较简单。如果线程要和界面打交道的话事情就变得麻烦了，因为除了应用程序的主线程，任何线程不能访问任何可视的VCL部件。你不得不使用Synchronize方法等待主线程处理它的消息，然后在主线程中访问VCL部件。而MFC就没有这样的限制。
稳定性与完善程度：VC是老大哥

VC要比Delphi稳定和完善。VC的发展历史比Delphi长，微软的总体实力比Inprise强。VC的框架MFC经历了那么多年的发展和完善，功能非常全面，而且十分稳定，bug很少。其中你可能遇到的bug也更少。而且有第三方的专门工具帮助你避开这些bug。如此规模的一个类库，能做到这一点不容易。不要小看了这一点，很多专业程序员就是为这个选择VC的。因为尽管VCL比MFC的抽象程度高，封装较为高层，但由此带来的开发效率的提高对高手来说毕竟是有限的。而如果你遇到一个怪问题，调试了半天，发现不是你的代码有错，而是VCL的bug，你作何感想？虽说遇到这类问题的可能性很小，但对VCL的形象的影响可不小。Delphi的IDE太占资源，启动速度太慢，和某些显卡驱动程序冲突，VCL中有bug，调试器不够健壮，对不稳定的第三方控件没有防护措施 …… 问题多多，在这方面Delphi不如VC。希望Inprise能更上一层楼。顺便说一下，我们在网上看到有些人极言Delphi的不稳定，说几分钟出现20多次非法操作。Delphi的确不如Visual C++稳定，但也不至于如此呀。我估计是那位朋友的Delphi装了某些有问题的第三方控件，导致了Delphi的频频出错。不妨卸下那些控件试试？

可移植性：立足现实，放眼未来

Inprise正在开发Delphi的Linux版本，代号为Kylix。也许通过Kylix，用VCL构架编写的Windows程序向Linux移植成为可能。但这只是可能。因为在目前Inprise的兼容性工作做得并不好。低版本的Delphi不能使用高版本的VCL组件，而高版本的Delphi竟然不能使用低版本的VCL组件。真是岂有此理，我们很少看见软件有不向下二进制兼容的。如果Windows 98不能运行95的程序，Windows 95不能运行3.x的程序，Win 3.x不能运行DOS程序，你还会用Windows吗？如果Windows 95的程序必须经过重新编译才能在98下运行，98会卖得那么好吗？"同门兄弟"C++Builder和Delphi也不能互相使用对方的组件，甚至同一套VCL库的文件名也不一样。所以一个组件有for D1/D2/D3/D4/D5/C1/C3/C4/C5这些不同版本是常有的事，而且随着Delphi和C++Builder版本的升级可能还会增加。希望Inprise能先解决同门兄弟的兼容性问题。而微软的VC就没有这类问题。MFC1.0的程序也可以毫无障碍地在VC6.0下编译通过。

集成界面：宏观与微观

就大处说，VC的集成界面是不如Delphi的。Delphi仅仅一个Object Inspector就可以将VC的一堆Wizards比下去，何况它还有Code Explorer、ToDo List等。但从小处，又可以看出Delphi的不成熟。比如"自动完成"功能的智能化程度和提示详细程度不如VC，响应速度也没有VC快。

Visual C++所带的MSDN是一部"开发者的百科全书"，信息庞大，查询方便，这方面比Delphi更专业。很多帮助项都有源程序示范。

Delphi的OpenTools是完全面向第三方的开放系统，开发者可以修改很多Borland公司自身的功能，从IDE的可扩充性上说Delphi更好。

调试：细微之处见真功

Visual C++和Delphi的调试功能都非常强大，同时都具有单步可视化调试、断点跟踪、运行时改变变量、鼠标指向可以得到变量值等等功能。对DLL的输入输出也能方便的管理，能够进行源码级别的调试。

相对而言，Visual C++能够更加方便地看到变量的变化情况，这包括对结构可以展开成数据树，从而了解每一个变量的值，每一步调试，变化了的变量会加红，从而使调试更加方便。另外，Visual C++的块内存察看比Delphi也要方便。

当然，Delphi也有很多体贴的细微之处，比如在线程调试的时候，Delphi能够很方便地察看线程的变化，Visual C++却必须要弹出一个模式对话框。

数据库开发：Delphi一枝独秀

数据库支持是Delphi的强项。这主要体现在Delphi与BDE的无缝集成，以及Delphi提供的那一大堆现成的数据库操作控件。这是VC望尘莫及的。目前Delphi支持BDE、ADO、InterBase三种数据库访问方式。所有的方式都能拖拉到应用程序中实现可视化操作。正是因为Delphi对数据库类的包装，使得用户操作数据库不像在Visual C++中必须从开始到最后都要干预。明显地提高了开发速度。

Delphi中使用WebBroker控件还能很方便地构造出基于数据库的Web页面，通过HTML管理Web数据库。 Visual C++访问数据主要通过ADO和OLEDB，很多ActiveX控件也能添加数据库功能。但是没有像Paradox这样的桌面数据库，Access相对功能太弱了。也许SQL Server是不错的选择。

COM：新技术的力量

COM是组件对象模型的缩写。它是OLE和ActiveX技术的基础，COM定义了一组API和一个二进制标准，让不同的编程语言、不同平台的彼此独立的对象相互进行通讯。

COM是Microsoft制订的行业标准。但Delphi也为COM提供了强大的语言支持。支持接口、variant、宽字符串功能。这些对COM的封装确实比C++更方便。比如在C++（没有类框架）进行COM编程时，变体定义为oaidl.h文件中的VARIANT结构。要处理变体，必须手工调整oleaut32.dll中VariantXXXX() API函数对其进行初始化和管理，如VariantInit()、VariantCopy()、VariantClear()等等。

Visual C++实现COM编程有一种特殊的方法就是使用ATL。ATL使用Visual C++特有的多重继承来实现COM接口。虽然不见得实现COM服务和控制更容易，但是ATL和最新COM技术的接口，基于模板的构造都比Delphi强。ATL更有利于建立小巧、快捷的COM组件程序。

按目前通用的观点，Visual C++应用到COM服务程序更有优势，Delphi应用到COM组件程序更合适。

昨天，今天，明天

技术的进步在很多时候是此消彼长的。当初Borland的Turbo C和Borland C++几乎是C/C++程序员唯一的选择。微软的Quick C(现在还有人知道这个产品吗？)和Microsoft C/C++从来也没有成为过主流。但Borland C++又流行了多少年呢？不久就被新崛起的Microsoft Visual C/C++压下去了。于是Inprise(原Borland)拣起了当年Turbo Pascal和Borland Pascal的辉煌(事实上Borland的成名作就是第一个Pascal编译器)，全力推出了Delphi。Delphi当初推出时被称为VB杀手，但VB现在仍然活得挺好。毕竟微软是靠Basic起家的嘛，VB不是那么容易被打败的。Inprise想了想不和VB争了，使用Delphi的IDE和VCL配上C++语言，推出了C++Builder，又向Visual C++的市场发起了夹攻。C++Builder似乎是个不错的折衷选择了？再仔细想想！C++Builder的优点Delphi都有，但Delphi的优点C++Builder未必有。比如C++Builder的编译速度比VC还慢，哪能和Delphi比？而且因为VCL是Object Pascal写的，C++语言和VCL磨合得并不好。C++Builder的bug比Delphi还多，甚至Sample代码中还有错。VCL的部分功能不能使用，要靠嵌入pascal代码访问。C++Builder可用的第三方控件远没有Delphi多。

唉，真是金无足赤。Microsoft和Inprise，谁会笑在最后呢？

鱼和熊掌：艰难的选择

选择一个开发工具依赖于很多不同的因素，每个人都能因为某种语言的某个缺陷而放弃学习或使用这种语言。任何程序员都希望自己喜欢的工具能达到理想的境界，通过上面不完善的比较，我想大家都有自己的看法。我们认为影响大家选择开发语言的因素主要包括：

1）哪门语言更容易入门？
学习一种语言需要投入大量的时间和精力。开发程序的开发成本是值得考虑的现实。一个熟练的Delphi程序员和一个熟练的VC程序员工作效率是一样的。但是，成为熟练的程序员必须很快掌握一门语言的技巧。不幸的是，目前熟练的Visual C++程序员是十里挑一。相对而言，Delphi更适合初学者。

2）哪门语言有更多可继承的代码？
语言代码的可重用性是加快开发效率明显方面，从早期的过程、函数到现在的组件技术都是朝这个目标在奋斗。这两种语言对代码重用的理解是不一样的，Delphi主要通过VCL控件来实现代码重用，Visual C++实现起来就比较复杂。

3）语言自身的本性。
就技术(主要指应用框架)来说，Delphi目前领先于Visual C++。但稳定性和健壮性的不足又让我对Inprise"想说爱你不容易"。而VC尽管发展到今日已十分完善，但MFC框架已是明日黄花了。如果不使用MFC，目前又没有合适的替代品。根据你的需要和实际情况做选择吧。实际上Visual C++和Delphi也不是简单竞争关系。它们在许多领域并不重叠，甚至是互补的。到底怎样取舍，要根据你的项目特性决定。如果你开发系统底层的东西，需要极好的兼容性和稳定性，选Visual C++吧。你可以只调用Windows的各种API，不用MFC。如果你写传统的Windows桌面应用程序，Visual C++的MFC框架是"正统"的选择；如果界面部分占这个应用程序代码比例较大的话，或者Delphi中有相关功能的控件的话，Delphi是事半功倍的选择。如果你为企业开发数据库、信息管理系统等高层应用("高层"是相对于"低层/底层"而言的，不是说技术高级或低级)，而且有比较紧的期限限制，选Delphi比较好。如果你熟悉的语言是Object Pascal，又不打算学复杂的C++，那么Delphi几乎是唯一的选择。传统的观点是：Delphi适合编写Internet/Intranet、表格制图、数据库操作、高级用户界面等等。Visual C++适合编写设备驱动、COM服务程序、科学计算、控制台（console）程序、WinCE的应用和一些小的工具等等。应用范围的不同要求好的程序员同时精通这两门语言。

4）语言的前景和可扩充性。
Delphi是Inprise的旗舰产品之一，前景应当还是比较乐观的，而且Inprise已经在向Linux进军了，而微软还迟迟没有动作。遗憾的是，Inprise公司Delphi的创始人已经跳槽到微软去主持Visual J++和C#项目了。但愿对Inprise冲击不会太大。

微软的Visual C++的前景又怎样呢？Visual Studio 7.0就要推出了。这一版本将加强网络开发的特性。看来微软虽然被判解体，开发实力可是一点没打折扣。

另外，虽说MFC已稍显落后，但不是说它不值得学。事实上，不学MFC就等于没学VC。利用MFC框架开发程序仍然是目前开发桌面应用的主流模式，而且还会保持相当长的时间。微软公司CEO史蒂夫·巴尔默(Steve Ballmer)曾说，.NET流行还得等2－3年。那么，MFC至少还有2－3年的生命空间。在技术日新月异的IT界，2－3年实在是很长一段时间了。好好把握吧。即使你不使用MFC框架，花点时间看一下MFC的封装机制对你熟悉C++的OOP机制和Windows底层功能也是很有好处的。而VCL的源代码是Object Pascal的，对C/C++程序员就没有这个"额外"的作用了。

atommann · 发表于 2007-10-20 16:21:50

用 VB 只能开发 Windows 下的软件，最好选择跨平台的C, C++.

Python 是好东西.

gingin · 发表于 2007-10-20 16:31:24

.net呢，貌似没人考虑.net的，微软可是在强力支持中的，还打算把它跨平台的（包括到linux上）。
而且.net的话微软可是提供免费的express版开发环境的，业余开发的话，版权问题可以省一下了。
就算同样是vb，.net下能做多线程、做服务，比6强很多了。

ATmega32 · 发表于 2007-10-20 16:35:14

C++ builder也开始学

usbfish · 发表于 2007-10-20 16:38:15

呵呵，跨平台的界面可以用wxWidgets来作啊
移植超方便

armok · 发表于 2007-10-20 17:30:23

谢谢【12楼】 sdnr 转载的文章，本贴可以置COOL了！

armok · 发表于 2007-10-20 17:43:25

看完这文章，我决定选择 delphi 了。我也在这个问题上犹豫。

最大的原因是：　

数据库支持是Delphi的强项。这主要体现在Delphi与BDE的无缝集成，以及Delphi提供的那一大堆现成的数据库操作控件。这是VC望尘莫及的。目前Delphi支持BDE、ADO、InterBase三种数据库访问方式。所有的方式都能拖拉到应用程序中实现可视化操作。正是因为Delphi对数据库类的包装，使得用户操作数据库不像在Visual C++中必须从开始到最后都要干预。明显地提高了开发速度。

chengjia535 · 发表于 2007-10-20 18:19:23

我上礼拜开始学习Delphi，原因很简单，研究AVR309。

Scarlette · 发表于 2007-10-20 18:26:08

呃……阿莫老大，没有想到你和Windows端的开发脱节那么多年了啊，哈哈哈……

开开玩笑啦。不过希望你能注意一下上面文章的日期，明显是D4时代的，就是说大约是七八年前的。现在的Delphi对于数据库的访问方式基本上已经不再鼓励使用BDE了，不过继续保留，主要是为了用户遗留代码的兼容性。现在主推的方式包括dbGo（就是ADO），IBExpress（Interbase的原生接口），以及dbExpress 4。尤其是dbExpress 4（Delphi 2007里新加入的，2006和以前的Delphi里版本是3），是个非常牛叉的原生数据引擎，极其高效，支持所有主流的RDBMS，而且可以自己写针对某个RDBMS的驱动加以扩展。拖几个组件到Form上试试看就知道了。

另外，delphi开发多层的数据库应用或者Web应用可以说是极其牛叉，而且DevExpress、atozed等公司还有一大堆超牛叉的控件包……

不过话说回来了，Delphi我不是用来写数据库应用的，数据库部分只是以前玩过几天而已，哈哈。

Scarlette · 发表于 2007-10-20 18:36:44

不过还有一件事，就是Delphi 2007的Help有点比较吐血，缺失了不少，据说Update 3打过以后好了很多。估计是CodeGear公司从Borland公司剥离出来的过程中造成的一点混乱吧，预计下一个版本应该不会再出现这种事儿了。

如果想玩Delphi，可以从Delphi 2006开始入手（2006的Help没什么太大问题），熟悉以后切换到2007。

j805 · 发表于 2007-10-20 18:44:14

会什么用什么!

我只会VC,所以只喜欢用VC.

lixun00 · 发表于 2007-10-20 20:05:02

呵呵，经典的文章。。。

sdnr · 发表于 2007-10-20 20:15:34

其实想来大家都会或多或少的从自己所熟悉的语言和编译器来思考问题。或许delphi2007本身就是用C++完成的，这也说不定（我不清楚，请高人不要拿板砖拍我）。个人觉得任何工具都是为了解决问题的，只要能很好的解决问题，而且兼容性好、移植方便，那就可以了。如果是会很多种语言，结果没有一样可以深入下去，那只能是蜻蜓点水，不会有什么进步。

armok · 发表于 2007-10-20 20:57:25

我是一直使用 oracle developer 开发应用软件的，它是专门为oracle database 而设计的开发工具。开发数据库管理软件既可靠，效率又高。

不过可惜的是，ORACLE的应用已经慢慢开始全部转向了JAVA，这个开发工具的寿命也快终结。现在想开了：任何开发语言，也只是生存一段时间，好用就行 :)

sdnr · 发表于 2007-10-20 21:17:55

阿莫说的好。据说北京大学的图书馆管理系统是用VF写的，也是速度又快，效果又好。

Scarlette · 发表于 2007-10-20 21:30:52

【24楼】 sdnr：

随便说说哈，不是拍砖——

Delphi本身从编译器到IDE都是Pascal写的。Borland公司最早的Turbo Pascal 1到3的编译器是Anders Heljsberg这个牛人用汇编写的，Phillip Karn用它写了界面（1-3的版本没有IDE的，只有很简单而且很丑的字符界面，估计各位都没见过吧，呵呵）；之后所有版本的Pascal的编译器都是Pascal写的，由上一代的编译器编译；然后由这个新版本的编译器写对应版本的IDE。

而且有一个最让很多人无法接受的地方，就是C++ Builder（包括编译器和IDE）其实是Pascal写的。准确的说，X+1版本的Delphi和X+1版本的C++ Builder都是由X版本的Delphi同步进行开发的，只是进度上的差异和商业策略导致发布时间的不同。Borland的很多其他重要产品也是Delphi写的，谁让人家就是Pascal的事实工业标准呢，呵呵。

还有就是，曾经非常惊讶的发现，CodeVision居然是用Delphi写的，有点很想不通，干嘛不写个Pascal Compiler for AVR呢。

linyu0395 · 发表于 2007-10-20 21:35:43

这也需要讨论？哪个用熟悉了绝对比半拉子的人要强大的多

binglin · 发表于 2007-10-20 21:37:46

我一直都是用delphi6,用了有6、7年了，为单位写的软件全都是用它。

之前也是delphi5。

别人怎么说我才不管，反正自已爱用什么就用什么。

sdnr · 发表于 2007-10-20 21:46:47

感谢Scarlette 指点。刚才查了资料，看来pascal语言本身能力也很强啊，跟C++相比各有千秋。

armok · 发表于 2007-10-20 22:43:32

我们这里真的高手如云啊。

dellric · 发表于 2007-10-20 22:59:24

呵呵,我个人是事情逼急了用VB,闲的时候就用VC, 无聊的时候就用JAVA, 为了拖工期就用ASM(用WIN32汇编写),满足自己的征服欲望就现学一种语言写

binglin · 发表于 2007-10-20 23:12:46

我现在用得最多的就是用delphi开发MS SQL 2000的数据库应用软件,用ADO数据库访问方式,编译好了,直接复制一个执行文件到别的机上就可以运行,不用考虑要打包什么一大堆的程序库文件.

就算开发单机数据库应用程序也是一样,简单方便.

C语言学了十几年了,但从来没有在PC机上开发一个实用的软件.

pascal,在二十年前有一个操作系统就是用它写的,是运行在APPLE II上的,当时学pascal时,编译一个程序要用七张软盘插来插去.

elefan · 发表于 2007-10-21 11:57:50

高手如云拉，这个贴子我要回去研究研究，正在犹豫使用哪种语言呢。

favr · 发表于 2007-10-21 15:38:27

大家都说开宝马座奔驰，庸俗一点，好车是买来摆的，“烂车”是买来开的。
“选语言”也是一样，当你急着拉货时不要等赚够钱买一辆宝马来做嘛。

ndust · 发表于 2007-10-21 16:21:43

熟悉哪种语言采用哪种语言。还有要根据需求，选择合适的语言开发。

我vb,delphi都能比划一下，c只写过dos下的程序。一直想学vc，没有太多的时间。

经常听说语言不用掌握太多，精一门就行，但我也不反对多掌握几门语言，时间、精力够用，越多越好，呵呵。

我玩过的语言：asm,c,dbase,foxpro,apple II basic,ibm gwbasic,pp-700(pc-1500) basic,qbasic,asp,delphi,vb,sql,flash 脚本语言。都一般，这些都是3年前鼓动过的，这3年一门语言也没学，本打算jsp,java,c#,vc,c++ builder,但是一直没有时间，争取以后也玩一下。

上个星期六下午，因为要做pxe网络启动盘，netbeui2003不支持了，而且克隆盘只支持一个用户，于是有做了ipxodi,tcpip的启动盘，在仿真软驱用到subst命令，但是版本不对，用debug修改subst.exe程序，让他跳过版本检查，原先以为忘了，那是在10年前大学玩的，没想到10几分钟也慢慢熟悉起来了。

看来是知道的越多越有用呀。今天下午用c写了一个在dos下备份和写入cmos的程序，用来批量安装计算机时自动设置cmos参数，在文本状态下编程，感觉真好。

ainet · 发表于 2007-10-22 08:18:33

在学校的时候，先学的pascal,后学的c语言.顺便了解了点汇编(dos)
出来工作头一两年，用的是vb(工业控制)
后几年到现在，用vc来做工程(工业控制)
将来，准备用linux下的c语言开发..

哎，什么时候是个头啊？

national6 · 发表于 2007-11-7 23:52:19

大家不要学DELPHI了，，它和GCC是有冲突的，

Error makefile 451: Command syntax error
Error makefile 452: Command syntax error
Error makefile 453: Command syntax error

Error makefile 454: Command syntax error
Error makefile 457: Command syntax error
Error makefile 458: Command syntax error
Error makefile 460: Command syntax error
Error makefile 461: Command syntax error
Error makefile 463: Command syntax error
Error makefile 465: Command syntax error
Error makefile 466: Command syntax error
Error makefile 521: Colon expected
Error makefile 530: Colon expected
Error makefile 552: Too many rules for target 'obj/%.o'
Error makefile 562: Too many rules for target '%.s'
Error makefile 569: Too many rules for target 'obj/%.o'
Error makefile 598: Command syntax error

national6 · 发表于 2007-11-7 23:54:06

这个错误肯定是DELPHI本身内在的问题，，就像男人生不儿子一样，，永改不了的，，因为它加了一个叫什么synlunik

usbfish · 发表于 2007-11-7 23:54:10

坚决捍卫Delphi，和GCC没有问题的！楼上的要检查自己电脑了。

national6 · 发表于 2007-11-8 00:00:11

晕哦，，有没有问题，，用户肯定知道的，，我也是装的D7，，但不是什么LITE版

usbfish · 发表于 2007-11-8 00:05:40

楼上的，你这么说就对了，如果真的如你所说这个问题存在的话，为什么我们讨论到现在，就你一个人“发现”了呢？
难道楼上的诸位都没一个人发现么？
再说了，就算真的有问题，你也不用每个帖子挨个发一遍啊，这点我很不喜欢。
因为我是Delphi和GCC的忠实fans

boat030 · 发表于 2007-11-8 00:23:57

C++ builder, 易学, 好用, 我学了3天就上手了!

martal · 发表于 2007-12-1 14:58:33

我三种语言都有过接触,最后抛弃delphi,选择了VB和VC
原因很简单:
选择VB,是因为简单的开发,只需要写具体实现代码,轻松而快速搞定!
选择VC,是因为功能强大,当需要实现的功能复杂了的时候,使用VC反而更加条理清晰,最关键的是,作为与下位机配合的上位机程序,很多时候两者(c与VC)的程序基本可通用,能很好的配合或移值,大大缩短了开发时间!
然而,delphi,简单不如VB,功能不如VC,最可惜的是,下位机的程序不能直接或快速地移植到上位机程序里...
所以,我觉得做单片机自动控制的,最好还是选用VB和VC

avruser · 发表于 2007-12-1 15:02:43

说了半天就是为了“下位机的程序不能直接或快速地移植到上位机程序里”啊，，，，，，，那可以用BCB嘛

biao · 发表于 2008-1-7 14:22:41

C++ builder的入门资料那有,可以给个连接?
谢谢

singleooo · 发表于 2008-1-7 20:19:30

哪个方面用哪个
不同人习惯不同的

zldiy · 发表于 2008-2-20 17:34:28

天啊
说的我也不知道该使用那中工具了，，刚刚下来DELPHI可是没有注册，也不知道该怎么注册。又看了这些，现在又不知道该用那中工具了。。。

eeyrw · 发表于 2008-2-20 18:09:39

用C#.NET吧

dbzard · 发表于 2008-2-21 22:16:24

我也被这个问题困扰.....
不过，因工作需要，现在只能用labview

apcfy · 发表于 2008-2-23 13:51:43

用什么工具并不重要，只是个工具，达到目的就行了！何必为这个伤脑筋呢。。我想好了，用VB！易学易用，学好这个再考虑学其它！

jizzll · 发表于 2008-3-12 21:06:03

看完老我就不知道选什么老

Feeling_MCU · 发表于 2008-3-12 21:38:56

C++builder吧,如果你对basic.pascl语言不熟,不想去钻研vC,那么BCB绝对是比较明智的选择

网上资料也很多,上手很快

our_avr · 发表于 2008-3-18 17:15:19

gerbee · 发表于 2008-3-18 17:26:47

公司用labview

vivalite · 发表于 2008-3-26 15:24:18

Java不错！我们公司的机器SUN Unix、Windows、Mac、手机都有，一个程序想在所有平台上都能运行似乎只有Java做得到。

不少人觉得Java慢，实际上只要做界面时用AWT，运行速度和VB没有两样。

至于另一个多平台编程语言Python也是不错的，不过因为先天是开源软件的缘故采用的风险比较大，而且Python又没有手机操作系统的广泛支持。

至于Windows平台，我喜欢用VC写核心，VB写界面，两者结合起来效果相当不错。

lovecsu · 发表于 2008-4-4 23:42:08

哈哈，感觉学vc++确实很苦

wisebaby · 发表于 2008-4-7 21:42:48

受教了，今后编写上位机程序，知道用什么软件比较好了，我打算把这些软件用个遍，现混个脸熟。

tdmi · 发表于 2008-4-8 12:32:04

以前用Delphi，现在用Labwindows/CVI

gerbee · 发表于 2008-4-10 15:02:31

如果只是做简单的东西的话推荐bcb 如果做嵌入式经常跨系统移植的话推荐java 和linux 如果不做wince的驱动的话推荐c#

aChip · 发表于 2008-4-21 17:42:55

Delphi虽然被borland遗弃了,但现在还有Lazarus这个开源的项目,非常接近Delphi了,使用FPC,可以一处编写到处编译(跟java的一处编译,到处调试相映成趣).
只要对Delphi熟悉,在Wince和Linux开发易如反掌.
所以Delphi还是有值得学习之处的.

Scarlette · 发表于 2008-4-22 01:38:31

倒塌……楼上的兄弟请不要胡乱吓唬不知情的群众，捧FreePascal也要讲究方式方法，搞得像中宣部就不好了，呵呵。Tiburon（Delphi 2008的代号）的Preview看了没有？超强啊。

至于说FPC，靠，恨铁不成钢啊，玩过一阵子，结果是“基本被它放倒”，没胆子敢用它做工程。Lazarus就别提了，离实用阶段还远的很。

xcm_gz · 发表于 2008-4-22 11:48:39

听说这年头已经是java在横行了。

hushenghong · 发表于 2008-4-22 12:41:30

C++ Builder

lwy86 · 发表于 2008-4-22 13:02:01

还是Labview最简单。

sciencehero · 发表于 2008-4-28 16:46:40

再次关注

525133174 · 发表于 2008-5-10 18:02:40

哇!大讨论啊!
收藏起来

radio · 发表于 2008-5-11 21:13:34

阿莫在18楼的选择没错, 除了数据库, 串口应用方面也有控件, 比VC用WINDOWS API操作方便,比VB用activex操作要简单.

另外,大家业余制作也好,还是公司做项目也好,其实快速应用开发是排第一位的,DELPHI可以帮助你实现快速的应用程序开发,比VC快得多.先实现,才能谈发展,否则就变成纸上谈兵,弄不好就说到汇编去了...

feverkim · 发表于 2008-5-18 19:50:11

DELPHI + LABVIEW 强强联手，通过DLL连接

delphi :负责各种外设通信，数据存贮，逻辑分析
LABVIEW：界面显示

afctl · 发表于 2008-9-4 13:58:00

还是学VC吧
以后用得到的地方多

carmen816 · 发表于 2008-9-4 19:30:10

不涉及驱动程序的开发，我想应该选择Delphi或者C++ Builder,如果你熟悉C语言的语法，那么用C++ Builder吧
反正Delphi和C++ Builder基本上差不多的

tomy · 发表于 2008-9-16 19:18:23

嗯，，前辈们给新手指路了，不过在VC和Delphi上还是很难选择，，，但是考虑到时间性，，决定选择Delphi~~~

看过了VB,,,VC,,,等一些的讨论我终于做出了决定，，

、

先顶起这个讨论先~~~

cgbabc · 发表于 2008-10-18 20:52:47

最近也在搞这个，路过学习

gliet_su · 发表于 2008-12-22 20:37:02

想学什么就学什么，没必要选这选那。

有人是小汽车，有人一开始就学大卡车。

并不见得学卡车的开不好。

shotstar · 发表于 2008-12-22 20:41:45

labwindows cvi /labview   怎么样 觉得

wyb4993 · 发表于 2008-12-23 19:47:51

我现在用的是labview。

mx123 · 发表于 2008-12-24 13:58:37

严重支持CVI

zcllom · 发表于 2008-12-24 15:12:40

labview大家用什么版本的？PJ了吗？教程多不多

wyb4993 · 发表于 2008-12-26 07:55:53

labview最新的版本是8.6，NI（美国国家仪器）公司在2008年8月1日发布。请参考NI公司的官方介绍：http://www.ni.com/labview/zhs/

网上已经有8.6版本的keygen，可以把NI网站下载的labview 8.6评估版，注册为labview 8.6中文专业开发版。

请参考我做的USB数据采集板，支持支持labview串口波形显示和虚拟仪器开发：

http://www.ouravr.com/bbs/bbs_content.jsp?bbs_sn=1995058&bbs_page_no=1&bbs_id=1006

Iressa · 发表于 2008-12-26 08:13:14

labview 靠他以后吃饭困难

ahong522 · 发表于 2008-12-26 08:32:31

学什么就什么好！

Canbus007 · 发表于 2008-12-27 16:53:43

了解！！

路过io

cboy12345 · 发表于 2009-1-6 21:00:30

vb容易上手，其它的难度都比较大，

shangzhenwei · 发表于 2009-5-25 18:04:06

看了这个帖子之后，头都大了。。先用VB吧，用好了之后，再学别的。

gdyaojie · 发表于 2009-6-3 22:45:12

从来没有编过程序, 而且也没有软件方面的功底, 用VB;
有PASCAL基础的, 用DELPHI; DELPHI在中国得到流行, 有一个比较大的功劳, 就是大学里面的数据结构, 算法结构等教程, 是用PASCAL写的, 原因就是PASCAL的语法严谨, 有助于培养学生的良好习惯. 这一点, C类的语言灵活性更适合熟练的程序员.  所以DELPHI在中国, 更容易被接收.

打算一直从事软件事业的, 用C类族的语言: C, C++, C#, JAVA等等, 还有与之相关系的开发工具, 和各种SDK, framework. 这条路走下去, 而且有毅力的话, "钱"途无量.

不过说实话, 我是不推荐VB, DELPHI, C++ Builder之类的, 如果你在软件行业做久了, 你就知道一件非常重要的事情, 也是这个论坛的所有大虾忽略的事情:  任何语言单独是无法存在的, 必须依附于某个框架, 才能发挥语言的特色, 离开了框架, 你寸步难行. 所以不推荐的原因是, 这几个语言的生命力已经到头了, 各大软件巨头的重心已经不在这些旧语言或者开发工具了. 你用来学习可以, 但是有一天你会发现, 为了实现某个功能, 你会很痛苦. 不要告诉我, 你很牛B, 打算从主板设计, 操作系统到开发语言, 到开发工具, 到应用软件等, 全部自己一手搞出来.

x9fish · 发表于 2009-6-3 23:51:04

工控上下位机，首要要求是什么？可靠性！。。。所以除了界面可以多种选择为，底层毫无疑问应该用最接近asm的c。从打基础角度看，首先应该精修c和c＋＋。至于ide用vc和builder都无所谓，尽可能编出符合ansi规范的代码。学习难度。。。。想用来谋生又怕难？？只学c和c＋＋并不以此谋生的飘过。

x9fish · 发表于 2009-6-3 23:52:46

哈哈和86楼握手

shangxf · 发表于 2009-6-4 00:08:47

VB做界面，关键部分用VC做成DLL给VB调用，下位机用C，怎么样？

cnzhy88 · 发表于 2009-6-4 00:15:57

我觉得的刚学用VB上手快，

gdyaojie · 发表于 2009-6-4 11:49:24

回89楼:
在VS6.0的时代, MS的建议就是这样的, RAD用VB, 其他用VC.
不过目前来看, 如果你想追潮流, 而且想自己的软件生命力可以延长下去, 可以用C#或者JAVA来写, 当然硬件底层的还是ASM和C为主. 而且C#, JAVA目前在嵌入开发方面, 特别是手机应用软件方面, 也是有一席之地的.
推荐C类族语言, 是因为目前的企业开发, PC底层开发, 主流的语言和framework, 都是基于此的.

gdyaojie · 发表于 2009-6-4 12:47:18

回87楼:

可靠性确实最重要, 而且是最基本的, 无论你是写何种类型的软件, 企业级的, 工业级的, 单机用户级的, 娱乐级的, 谁都不愿意用一个经常当机,非法退出的软件吧.

软件和硬件不同, 可靠性这东西, 其实我的理解, 只要你用的开发工具是主流的开发工具, 工具本身是没有问题的, 关键在于开发的人员的素质如何. 现在的开发人员老喜欢把软件的BUG推到操作系统, 开发工具身上, 其实99%是他自身的问题. 无论工具多么容易上手, 想熟透从而利用好开发工具的特性, 不要说一两个星期, 一两个月都不可能, 而且每个工具都是针对某个领域而设计的, 都有其特点. 代码风格, 程序结构, 使用习惯, 甚至控件的设置方法, 都有自己的特点, 所以没有熟练使用过某个工具之前, 是没有资格对其评头论足的.
工具的使用是有区别的, 没有区别的, 是软件设计思想.

onebobo126com · 发表于 2009-7-12 21:29:14

Cool

xiao5333 · 发表于 2009-7-12 22:14:54

jianguang_3 · 发表于 2009-7-17 10:39:57

MCGS

tssing · 发表于 2009-7-19 14:34:24

大家好，，，
net肯定可以满足你所有的需要，，，非常的简易使用。。。

他的控件非常多，chart控件已经嵌在里面，报表等，
还自带sql数据库，，打包工具。。

主要他是微软的，，大家可以考虑考虑。。。

hyl175 · 发表于 2009-8-21 08:03:17

还是推荐一下Labview

lffpga · 发表于 2009-10-13 22:30:36

Cool

isbit · 发表于 2009-11-19 22:42:26

看完反而不知道选啥了，晕！

gongxd · 发表于 2009-11-20 08:36:01

想搞下上位机，麻烦大家推荐下用哪个软件比较好？是C++还是其他？

阿莫论坛20周年了！感谢大家的支持与爱护！！