本人已经离开软件行业多年了，现在主要是做做小生意，炒炒股票，但也经常关注一下软件业的发展，这几天心血来潮，下了个LAZARUS，玩了一下，一下子被它迷住了，感叹真是太牛了！现在把这几天玩的感受写下来，从各个方面比较，供大家看看。
先说下LAZARUS是个啥东西，它是一个OBJECT PASCAL的集成开发环境，其编译器用的是FREE PASCAL，跟DELPHI 几乎一个模样，很多基本的单元，类库，都是用同样的名字，会DELPHI 的人毫不费力就可以使用LAZARUS，凡是FREE PASCAL编译器能运行的平台，LAZARUS就能运行，口号是：“一次编写，到处编译”，官方网站是：http://www.freepascal.org/
为了简单点，把FREE PASCAL/LAZARUS统称为FPC
1） 运行硬件平台：
DELPHI ：仅仅在INTEL X86上运行。
FPC： INTEL、POWER PC、SPARC、ARM\ 、Motorola 680x0等，同时还支持64位
2）操作系统：
DELPHI： WINDOWS。
FPC： Linux, FreeBSD, Mac OS X, DOS, Win32, Win64, WinCE, OS/2, Netware (libc and classic) and MorphOS，其最新版本2.4还支持IPHONE、SymbianOS。看起来比DELPHI 多的多了。
更牛的是：可以为没有操作系统的一些微控制器开发程序！从这点上，可以与C平起平坐了。
3） 图形库接口
DELPHI(VCL) ： WIN32：
FPC(LCL)： WIN32/64、GTK、QT、WINCE、MAC OS X 的COCOA等等。
4） 第三方控件库：
相对来说，FPC要少些，但现在移植的工作非常快，很多重要的库都可以从DELPHI 那里移过来，比如著名的网络控件INDY 、数据库访问控件：ZEOSLIB都能在LAZARUS下使用了。
我做了下测试，在DELPHI 下创建一个窗体，上面堆满了很多控件，然后在LAZARUS下用它带的功能转换一下，一些最基本的控件（如STANDARD页和ADDTIONAL页的），不用任何修改就能用，其他的有可能用不了，随着以后移植的增多，相信大部分都能用，但在运行的时候，老会出现一个DOS窗口，不知道是啥原因，我还没搞清楚。
5)语言区别：
都是OBJECT PASCAL语言，高度兼容DELPHI ，其类，封装，关键字等都一样，但我发现，FPC在某些方面引用了C的风格，如：+=、 -= 、*=、/=。而在DELPHI中，这是不行的，从我个人角度看，不赞成这种写法，这会让代码变得复杂，破坏PASCAL语言的简明。RTL运行库的函数也几乎全部一样，真的很佩服那些牛人，要搞出这样的东西出来，确实要花不少心血的哦！
在FPC的2.4最新版本中，引进了FOR .. IN .. .DO循环，可以兼容DELPHI 2010了。其实我觉得PASCAL语言中，要把FOR … TO … DO 改进下，增加一个STEP，这样就可以加快某些情况下的循环，而现在只能每次加1个，效率有时候就低了。其他语言都可以的，比如 MODULA都有，不知道以前的BORLAND和现在的CODEGEAR为啥不加？很难吗？
在UNICODE支持方面，FPC早就支持了，DELPHI 直到2009才开始。FPC用的UTF8，DELPHI 用的UCS-2方式。
在测算的时候是不同的，比如一个字符串：“abcdefg程序”，如果在DELPHI 2010中，用LENGTH算出的长度是9，而在FPC中则是13。在UTF8中，非ASCII码用三字节编码，而在DELPHI 中，无论中文英文，都看成是一个字。所以才造成这样的区别。
所以同样的字符串在DELPHI 和FPC中得出不同的长度，千万不要大惊小怪。
在64位支持方面：FPC早就有了，而DELPHI 现在都还没点影，真搞不懂那么多专业工程师怎么干不过这些业余的呢？DELPHI 这几年确实太没落了，啥也没改进，整天跟MS后面玩.NET，结果玩到半途，发现这样玩下去，小命也没了，才又反回来。可惜浪费太多时间了。
6）代码编辑器：
我个人感觉，其编辑器要比DELPHI 7好用，风格跟DELPHI 2010差不多。
7）编译效率：
FPC比DELPHI 要慢一些
8）执行效率：
我写过一个对整数的快速排序算法，随机生成个数，存在数组中，数据规模是5000万，FPC比DELPHI 7要慢30%。
我又测试了浮点数计算：数据规模也是5000万，测试时候分成二个方面：
一个是只做基本的加减乘除：如这样的公式 sum := sqrt(sum+((arr_float[i] / arr_float[i-1]) / 7.7) * 0.056) ; FPC也是比DELPHI 7慢30%左右。
但在进一步测试科学计算时，FPC慢很多了，将近慢1.5倍。如增加了一条语句： sum := power(sum,random * 1.5)+sin(100 * 3.14/180)+cos(100 * 3.14 /180)+log10(sum * 100); 也就是说，FPC在进行POWER，SIN,COS,LOG等函数计算时，效率下降很快，我大致看了下，发现RTL中，FPC是用PASCAL写的函数，而DELPHI 很多使用汇编写的。但如果只是语言差异，效率应该也不会下降那么多，应该还跟一些算法有关。
在这方面，FPC应该还有很大的改善空间，一是提升编译器本身，二是改进RTL库。在RTL库方面，DELPHI 最新的版本中，都引进了开源的FASTCODE，我想FPC应该也可以引进，移植到FPC上面来，这样就可以利用开源的成果，快速提高RTL品质，如果什么都要自己造*的话，那效率就会太慢了。
如果FPC在整体效率上能与DELPHI 缩小到10%左右的差距时候，那FPC的实际应用领域就大大拓展了！会给DELPHI 造成极大的威胁。
顺便提一下，前几天下了个DELPHI 2010，跟DELPHI 7对比测试后，发现DELPHI 2010要比DELPHI 7慢那么一点点，大概在3-5%之间。当然，DELPHI 2010也加了很多花哨的东西，比如泛型模板、反射等，由于没有许可，只能用14天，还时不时弹出公司试用许可警告，要重新启动才能用，一怒之下，把它删除了。
9）程序体积：
不得不说，FPC编译后的程序体积太大了，当然，如果去掉调试信息后，体积可大幅度减少，但还是比DELPHI 大很多，这是非常需要改进的地方。
10）结论：
总体上，FREE PASCAL已经很不错了，做一些要求不是很高的软件开发，没啥问题。同时其发展速度很快，假以时日，应该会有很好的表现，特别对于需要做跨平台的开发，FPC是一个非常好的选择。
Tony tang
2009-12-12
深圳
51 个解决方案
#1
关注一下.
#2
一直想为wince的手机写点工具，不知道fpc是不是方便。。。。。。。。
#3
看完了
只羡慕楼主 “已经离开软件行业多年了，现在主要是做做小生意，炒炒股票”
只羡慕楼主 “已经离开软件行业多年了，现在主要是做做小生意，炒炒股票”
#4
DELPHI 现在不关心用哪个编译器
现在只是学习VCL里设计模式的应用，有些真精彩
现在只是学习VCL里设计模式的应用，有些真精彩
#5
另外在指针方面，FREE PASCAL也做了改进（DELPHI 2010也一样），可以象C语言那样，用数组形式来方便地用了。
以前定义个指针，比如P:^INTEGER；不能用P+1的形式来增加指针运算，只能用INC(P)或者其他变通的形式来做，非常麻烦，现在可以象C语言那样，直接用P[I]或者(P+I)^的形式来处理。
以前定义个指针，比如P:^INTEGER；不能用P+1的形式来增加指针运算，只能用INC(P)或者其他变通的形式来做，非常麻烦，现在可以象C语言那样，直接用P[I]或者(P+I)^的形式来处理。
#6
我认为该评价比较客观真实
也不知道怎么回事，FPC的手感总不如D7
字体怎么设置也不好看
也不知道怎么回事，FPC的手感总不如D7
字体怎么设置也不好看
#7
虽然DELPHI 新版中对指针运算进行了改进，但还可以继续改进，在多级指针运算上，还是不如C灵活，
比如有如下程序，用数组指针对一个二维数组进行操作。
TYPE
PARR = ^TAI;
TAI = ARRAY [0..3] OF INTEGER;
VAR
ARR: ARRAY[0..10,0..3] OF INTEGER;
I, J: INTEGER;
PP: PARR;
begin
FOR I := 0 TO 10 DO
FOR J := 0 TO 3 DO
ARR[I,J] := I * J;
PP := @ARR[0,0];
FOR I := 0 TO 10 DO
BEGIN
FOR J := 0 TO 3 DO
BEGIN
LISTBOX1.ITEMS.ADD( INTTOSTR((PP+I)^[J]) ) ;
////注意下面一行，按道理，是可以通过的，C语言就可以用 *(*(PP+I)+J)形式来访问，
//但DELPHI 2010/free pascal 现在还不行，只能按照上面的方法来访问，不知道既然一级指针，
//可以，而二级指针却不行？还是我用错了？。
// LISTBOX1.ITEMS.ADD( INTTOSTR( ((PP+I)^+J)^ ) ) ;
END;
LISTBOX1.ITEMS.ADD('--------------------');
END;
end;
比如有如下程序，用数组指针对一个二维数组进行操作。
TYPE
PARR = ^TAI;
TAI = ARRAY [0..3] OF INTEGER;
VAR
ARR: ARRAY[0..10,0..3] OF INTEGER;
I, J: INTEGER;
PP: PARR;
begin
FOR I := 0 TO 10 DO
FOR J := 0 TO 3 DO
ARR[I,J] := I * J;
PP := @ARR[0,0];
FOR I := 0 TO 10 DO
BEGIN
FOR J := 0 TO 3 DO
BEGIN
LISTBOX1.ITEMS.ADD( INTTOSTR((PP+I)^[J]) ) ;
////注意下面一行，按道理，是可以通过的，C语言就可以用 *(*(PP+I)+J)形式来访问，
//但DELPHI 2010/free pascal 现在还不行，只能按照上面的方法来访问，不知道既然一级指针，
//可以，而二级指针却不行？还是我用错了？。
// LISTBOX1.ITEMS.ADD( INTTOSTR( ((PP+I)^+J)^ ) ) ;
END;
LISTBOX1.ITEMS.ADD('--------------------');
END;
end;
#8
如果
((PP+I)^+J)^ 这样的形式也可以的话，那就真正可以跟C的指针一样*方便了。
#9
#10
今天第一次下载了：
2008-08-04 03:01 9,472,480 fpc-2.2.2.arm-wince.exe
2009-12-13 10:08 36,295,445 fpc-2.2.4.i386-win32.exe
反正对于d7之后的版本也不感兴趣了，如果freepascal可以写win32/64/ce下的程序，反而更好了！
2008-08-04 03:01 9,472,480 fpc-2.2.2.arm-wince.exe
2009-12-13 10:08 36,295,445 fpc-2.2.4.i386-win32.exe
反正对于d7之后的版本也不感兴趣了，如果freepascal可以写win32/64/ce下的程序，反而更好了！
#11
很久以前就对fpc有所了解，我一看协议时gpl就没兴趣打理它了。我为什么不用更加成熟的gcc与更先进、现代化的llvm/clang?
#12
相比与delphi的费用，gpl也算是免费了，毕竟一般人只是利用它开发、编译自己的程序，
用freepascal开发、编译的自己的程序不用开放源码吧？
能跨平台，简单的客户端程序设计、调试界面与delphi类似，就足够了
llvm/clang更先进、现代化的地方在什么地方呢？也许普通应用开发者暂时用不到
用freepascal开发、编译的自己的程序不用开放源码吧？
能跨平台，简单的客户端程序设计、调试界面与delphi类似，就足够了
llvm/clang更先进、现代化的地方在什么地方呢？也许普通应用开发者暂时用不到
#13
free pascal 的数组赋值也改进了，以前我在CSDN上批评DELPHI 的数组赋值问题，很多人还说顽固地维护
DELPHI 的做法。
比如以前二个同样的数组，只有声明在同一行才能互相赋值，否则，就说你类型不兼容，没办法编译，必须要再申明一个另外的类型才行，非常麻烦，也难以理解和困惑，
如：
var
arr,arr2:array[1..10] of integer;
begin
arr := arr2;
end;
可以互相赋值。
但如果写成：
var
arr:array[1..10] of integer;
arr2:array[1..10] of integer;
begin
arr := arr2;
end;
则没办法通过编译。
而在FREE Pascal里面，则只要类型相同，不管你在啥地方声明都可以互相赋值，这就对了。（DELPHI 2010我没有试过，D7以前都是不行的）
DELPHI 的做法。
比如以前二个同样的数组，只有声明在同一行才能互相赋值，否则，就说你类型不兼容，没办法编译，必须要再申明一个另外的类型才行，非常麻烦，也难以理解和困惑，
如：
var
arr,arr2:array[1..10] of integer;
begin
arr := arr2;
end;
可以互相赋值。
但如果写成：
var
arr:array[1..10] of integer;
arr2:array[1..10] of integer;
begin
arr := arr2;
end;
则没办法通过编译。
而在FREE Pascal里面，则只要类型相同，不管你在啥地方声明都可以互相赋值，这就对了。（DELPHI 2010我没有试过，D7以前都是不行的）
#14
ide是dos文本模式的？好像n年前的tc/tp？
我还以为是gui的。。。。。。。。。那也就不是拖放控件的形式了？
虽然拖放控件是高手、熟手所不屑甚至认为它是罪恶之源，不过对于入门、简单应用，拖放控件还是方便、快捷
#15
Lazarus －－ 带IDE的 free pascal. 最新的支持嵌入式开发了。
#16
GUI在这个(lazarus)：
http://www.lazarus.freepascal.org/
http://www.lazarus.freepascal.org/
#17
哦？lazarus是在freepascal之上发展的？我还以为2者是一回事。。。。。。。。。
#18
嗯，我想先把DE看明白了再说，顶一下。
#19
可以拖拉控件实现基本应用了！
treeview的demo
运行时的那个dos窗口，估计是调试信息的输出窗口，还未找到怎么屏蔽的参数。。。。。。。
选项有中文语言可以选择，但是菜单是不变的
ide上方的快捷按钮无法客户化，另外不知道有没有cnpack可以使用
想生成wince(好像说的beta)的执行程序，但是总是报错：
TV_Add_Remove.dpr(4,3) Fatal: Can't find unit Interfaces used by TV_Add_Remove
是不是wince应用的开发，不能使用拖控件的方式？
选择fpc\demo\wince下的sysinfo.lpi编译，也会报错：
sysinfo.pp(24,44) Fatal: Can't find unit aygshell used by sysinfo
把它所在的路径 \FreePascal\lazarus\fpc\2.2.4\units\arm-wince\winceunits\
加入项目编译选项的第一行：-Fu里面，按确认却反而报错：
下面2套wince，是不是只需要一套就够了？
2008-08-04 03:01 9,472,480 fpc-2.2.2.arm-wince.exe //b
2009-12-13 10:08 36,295,445 fpc-2.2.4.i386-win32.exe //a
2009-10-25 17:44 14,772,181 Lazarus-0.9.28.2-fpc-2.2.4-cross-arm-wince-win32.exe //d
2009-10-25 17:37 64,580,088 lazarus-0.9.28.2-fpc-2.2.4-win32.exe //c
我是a、b、c、d都顺序安装了。。。。。。是不是安装重复了？
treeview的demo
运行时的那个dos窗口，估计是调试信息的输出窗口，还未找到怎么屏蔽的参数。。。。。。。
选项有中文语言可以选择，但是菜单是不变的
ide上方的快捷按钮无法客户化，另外不知道有没有cnpack可以使用
想生成wince(好像说的beta)的执行程序，但是总是报错：
TV_Add_Remove.dpr(4,3) Fatal: Can't find unit Interfaces used by TV_Add_Remove
是不是wince应用的开发，不能使用拖控件的方式？
选择fpc\demo\wince下的sysinfo.lpi编译，也会报错：
sysinfo.pp(24,44) Fatal: Can't find unit aygshell used by sysinfo
把它所在的路径 \FreePascal\lazarus\fpc\2.2.4\units\arm-wince\winceunits\
加入项目编译选项的第一行：-Fu里面，按确认却反而报错：
下面2套wince，是不是只需要一套就够了？
2008-08-04 03:01 9,472,480 fpc-2.2.2.arm-wince.exe //b
2009-12-13 10:08 36,295,445 fpc-2.2.4.i386-win32.exe //a
2009-10-25 17:44 14,772,181 Lazarus-0.9.28.2-fpc-2.2.4-cross-arm-wince-win32.exe //d
2009-10-25 17:37 64,580,088 lazarus-0.9.28.2-fpc-2.2.4-win32.exe //c
我是a、b、c、d都顺序安装了。。。。。。是不是安装重复了？
#20
WINCE用的ARM处理器，如果在PC上开发，应该先要做个交叉编译平台吧？
具体怎么弄就不知道了，这要慢慢去研究。
具体怎么弄就不知道了，这要慢慢去研究。
#21
另外在WINCE 这些嵌入式设备上开发，一般不直接用LCL库，太庞大了，
有个一专门的嵌入式可视库KOL-CE吧？编译后，非常小。
有个一专门的嵌入式可视库KOL-CE吧？编译后，非常小。
#22
lazarus下过、用过，不是很顺手，还是跟着delphi。
#23
用C#吧. 呵呵.我用起来觉得很顺手.
#24
友情up！
#25
vs老是用不惯。。。。。。。。而且也大，还需要.net高版本
#26
下了一个，还不知道怎么运行~
#27
前段时间研究过，有两个大问题使我不敢用它，
1.如楼主所说，速度太慢，特别是数值运算时，同样的程序要慢N倍，头疼啊。。。
2.BUG不少，比如楼上说的那个KOL-CE，莫名其妙报错，一报错，整个工程就无法使用了。
不过还是非常看好FPC，希望它越做越好
1.如楼主所说，速度太慢，特别是数值运算时，同样的程序要慢N倍，头疼啊。。。
2.BUG不少，比如楼上说的那个KOL-CE，莫名其妙报错，一报错，整个工程就无法使用了。
不过还是非常看好FPC，希望它越做越好
#28
不懂
#29
我覺得以前的做法是比較合適的。加紅字部份。你只是聲明了兩個變量，并沒有定義array[1..10] of integer是一個數據類型，所以arr,arr2不能相互賦值。這反映出來，delphi其實不是很“高級”。呵呵。
#30
据称国外的牛人研究出一个方法，让FPC可以为iPhone编写应用。其实也不奇怪，支持ARM的编译器都应该可以。
#31
楼主跟威锋网的sztony 有关系吗？同一个人？如果是，谢谢你之前破的英文字典~
#32
我只是来拿每天的10分
#33
严重同意
#34
其实现在看，还不如Python发展的好
#35
真是好东西！
#36
最近刚开始用delphi2010,先熟悉下。
#37
看看.
#38
下了试了下，竟然乱码
#39
同羡!
Lazarus没有Delphi手感好.
#40
支持。。。
#41
为什么编译后的EXE那么大？？？
#42
我在想，是不是新出的Delphi XE又落后了。。。
#43
默认什么都不做的空窗体都近12M了，通过加壳最小2M多吧，比delphi做的大多了。
#44
吼吼！佩服你呀！不做软件好多年，写东西还是那么专业！以前应该是个高手啊
#45
太恐怖了
#46
设置一下Lazarus的编译条件，就可以很小了，忘记是哪个设置，网上搜索一下，很多的
#47
楼主胡说八道，一看就是没什么了解的，就在那装深沉，最BS这种人！
#48
我更倾向于用Turbo Delphi，控件带源码的不安装，直接引用。界面都用基本界面。
#49
我曾多次接触过Lazarus，给我的感觉并没有期望的好，但我仍然很关心它的发展，当然最终取决于FPC的发展，毕竟除了Delphi外，它是Object PASCAL家族最大的希望了。如果将来FPC的效率、性能能够更好，那么建立在它之上的Lazarus会更有竞争力。
#50
Delphi没用过，Lazarus装过两次，一次winXP 32bit,一次Linux,哪次也没上手！可能是我学得东西还不够吧，毕竟一直是业余的，最多也就参加过一次NOIP，用gedit编写，在终端用FP + GCC编译也对付的过去。但好像Lazarus支持窗口！FPC怎么编才能有窗口啊，以前在windows里用TP，也只能在调试时用窗口，一旦正式编译后就不行了，有人知道吗？
#1
关注一下.
#2
一直想为wince的手机写点工具，不知道fpc是不是方便。。。。。。。。
#3
看完了
只羡慕楼主 “已经离开软件行业多年了，现在主要是做做小生意，炒炒股票”
只羡慕楼主 “已经离开软件行业多年了，现在主要是做做小生意，炒炒股票”
#4
DELPHI 现在不关心用哪个编译器
现在只是学习VCL里设计模式的应用，有些真精彩
现在只是学习VCL里设计模式的应用，有些真精彩
#5
另外在指针方面，FREE PASCAL也做了改进（DELPHI 2010也一样），可以象C语言那样，用数组形式来方便地用了。
以前定义个指针，比如P:^INTEGER；不能用P+1的形式来增加指针运算，只能用INC(P)或者其他变通的形式来做，非常麻烦，现在可以象C语言那样，直接用P[I]或者(P+I)^的形式来处理。
以前定义个指针，比如P:^INTEGER；不能用P+1的形式来增加指针运算，只能用INC(P)或者其他变通的形式来做，非常麻烦，现在可以象C语言那样，直接用P[I]或者(P+I)^的形式来处理。
#6
我认为该评价比较客观真实
也不知道怎么回事，FPC的手感总不如D7
字体怎么设置也不好看
也不知道怎么回事，FPC的手感总不如D7
字体怎么设置也不好看
#7
虽然DELPHI 新版中对指针运算进行了改进，但还可以继续改进，在多级指针运算上，还是不如C灵活，
比如有如下程序，用数组指针对一个二维数组进行操作。
TYPE
PARR = ^TAI;
TAI = ARRAY [0..3] OF INTEGER;
VAR
ARR: ARRAY[0..10,0..3] OF INTEGER;
I, J: INTEGER;
PP: PARR;
begin
FOR I := 0 TO 10 DO
FOR J := 0 TO 3 DO
ARR[I,J] := I * J;
PP := @ARR[0,0];
FOR I := 0 TO 10 DO
BEGIN
FOR J := 0 TO 3 DO
BEGIN
LISTBOX1.ITEMS.ADD( INTTOSTR((PP+I)^[J]) ) ;
////注意下面一行，按道理，是可以通过的，C语言就可以用 *(*(PP+I)+J)形式来访问，
//但DELPHI 2010/free pascal 现在还不行，只能按照上面的方法来访问，不知道既然一级指针，
//可以，而二级指针却不行？还是我用错了？。
// LISTBOX1.ITEMS.ADD( INTTOSTR( ((PP+I)^+J)^ ) ) ;
END;
LISTBOX1.ITEMS.ADD('--------------------');
END;
end;
比如有如下程序，用数组指针对一个二维数组进行操作。
TYPE
PARR = ^TAI;
TAI = ARRAY [0..3] OF INTEGER;
VAR
ARR: ARRAY[0..10,0..3] OF INTEGER;
I, J: INTEGER;
PP: PARR;
begin
FOR I := 0 TO 10 DO
FOR J := 0 TO 3 DO
ARR[I,J] := I * J;
PP := @ARR[0,0];
FOR I := 0 TO 10 DO
BEGIN
FOR J := 0 TO 3 DO
BEGIN
LISTBOX1.ITEMS.ADD( INTTOSTR((PP+I)^[J]) ) ;
////注意下面一行，按道理，是可以通过的，C语言就可以用 *(*(PP+I)+J)形式来访问，
//但DELPHI 2010/free pascal 现在还不行，只能按照上面的方法来访问，不知道既然一级指针，
//可以，而二级指针却不行？还是我用错了？。
// LISTBOX1.ITEMS.ADD( INTTOSTR( ((PP+I)^+J)^ ) ) ;
END;
LISTBOX1.ITEMS.ADD('--------------------');
END;
end;
#8
如果
((PP+I)^+J)^ 这样的形式也可以的话，那就真正可以跟C的指针一样*方便了。
#9
#10
今天第一次下载了：
2008-08-04 03:01 9,472,480 fpc-2.2.2.arm-wince.exe
2009-12-13 10:08 36,295,445 fpc-2.2.4.i386-win32.exe
反正对于d7之后的版本也不感兴趣了，如果freepascal可以写win32/64/ce下的程序，反而更好了！
2008-08-04 03:01 9,472,480 fpc-2.2.2.arm-wince.exe
2009-12-13 10:08 36,295,445 fpc-2.2.4.i386-win32.exe
反正对于d7之后的版本也不感兴趣了，如果freepascal可以写win32/64/ce下的程序，反而更好了！
#11
很久以前就对fpc有所了解，我一看协议时gpl就没兴趣打理它了。我为什么不用更加成熟的gcc与更先进、现代化的llvm/clang?
#12
相比与delphi的费用，gpl也算是免费了，毕竟一般人只是利用它开发、编译自己的程序，
用freepascal开发、编译的自己的程序不用开放源码吧？
能跨平台，简单的客户端程序设计、调试界面与delphi类似，就足够了
llvm/clang更先进、现代化的地方在什么地方呢？也许普通应用开发者暂时用不到
用freepascal开发、编译的自己的程序不用开放源码吧？
能跨平台，简单的客户端程序设计、调试界面与delphi类似，就足够了
llvm/clang更先进、现代化的地方在什么地方呢？也许普通应用开发者暂时用不到
#13
free pascal 的数组赋值也改进了，以前我在CSDN上批评DELPHI 的数组赋值问题，很多人还说顽固地维护
DELPHI 的做法。
比如以前二个同样的数组，只有声明在同一行才能互相赋值，否则，就说你类型不兼容，没办法编译，必须要再申明一个另外的类型才行，非常麻烦，也难以理解和困惑，
如：
var
arr,arr2:array[1..10] of integer;
begin
arr := arr2;
end;
可以互相赋值。
但如果写成：
var
arr:array[1..10] of integer;
arr2:array[1..10] of integer;
begin
arr := arr2;
end;
则没办法通过编译。
而在FREE Pascal里面，则只要类型相同，不管你在啥地方声明都可以互相赋值，这就对了。（DELPHI 2010我没有试过，D7以前都是不行的）
DELPHI 的做法。
比如以前二个同样的数组，只有声明在同一行才能互相赋值，否则，就说你类型不兼容，没办法编译，必须要再申明一个另外的类型才行，非常麻烦，也难以理解和困惑，
如：
var
arr,arr2:array[1..10] of integer;
begin
arr := arr2;
end;
可以互相赋值。
但如果写成：
var
arr:array[1..10] of integer;
arr2:array[1..10] of integer;
begin
arr := arr2;
end;
则没办法通过编译。
而在FREE Pascal里面，则只要类型相同，不管你在啥地方声明都可以互相赋值，这就对了。（DELPHI 2010我没有试过，D7以前都是不行的）
#14
ide是dos文本模式的？好像n年前的tc/tp？
我还以为是gui的。。。。。。。。。那也就不是拖放控件的形式了？
虽然拖放控件是高手、熟手所不屑甚至认为它是罪恶之源，不过对于入门、简单应用，拖放控件还是方便、快捷
#15
Lazarus －－ 带IDE的 free pascal. 最新的支持嵌入式开发了。
#16
GUI在这个(lazarus)：
http://www.lazarus.freepascal.org/
http://www.lazarus.freepascal.org/
#17
哦？lazarus是在freepascal之上发展的？我还以为2者是一回事。。。。。。。。。
#18
嗯，我想先把DE看明白了再说，顶一下。
#19
可以拖拉控件实现基本应用了！
treeview的demo
运行时的那个dos窗口，估计是调试信息的输出窗口，还未找到怎么屏蔽的参数。。。。。。。
选项有中文语言可以选择，但是菜单是不变的
ide上方的快捷按钮无法客户化，另外不知道有没有cnpack可以使用
想生成wince(好像说的beta)的执行程序，但是总是报错：
TV_Add_Remove.dpr(4,3) Fatal: Can't find unit Interfaces used by TV_Add_Remove
是不是wince应用的开发，不能使用拖控件的方式？
选择fpc\demo\wince下的sysinfo.lpi编译，也会报错：
sysinfo.pp(24,44) Fatal: Can't find unit aygshell used by sysinfo
把它所在的路径 \FreePascal\lazarus\fpc\2.2.4\units\arm-wince\winceunits\
加入项目编译选项的第一行：-Fu里面，按确认却反而报错：
下面2套wince，是不是只需要一套就够了？
2008-08-04 03:01 9,472,480 fpc-2.2.2.arm-wince.exe //b
2009-12-13 10:08 36,295,445 fpc-2.2.4.i386-win32.exe //a
2009-10-25 17:44 14,772,181 Lazarus-0.9.28.2-fpc-2.2.4-cross-arm-wince-win32.exe //d
2009-10-25 17:37 64,580,088 lazarus-0.9.28.2-fpc-2.2.4-win32.exe //c
我是a、b、c、d都顺序安装了。。。。。。是不是安装重复了？
treeview的demo
运行时的那个dos窗口，估计是调试信息的输出窗口，还未找到怎么屏蔽的参数。。。。。。。
选项有中文语言可以选择，但是菜单是不变的
ide上方的快捷按钮无法客户化，另外不知道有没有cnpack可以使用
想生成wince(好像说的beta)的执行程序，但是总是报错：
TV_Add_Remove.dpr(4,3) Fatal: Can't find unit Interfaces used by TV_Add_Remove
是不是wince应用的开发，不能使用拖控件的方式？
选择fpc\demo\wince下的sysinfo.lpi编译，也会报错：
sysinfo.pp(24,44) Fatal: Can't find unit aygshell used by sysinfo
把它所在的路径 \FreePascal\lazarus\fpc\2.2.4\units\arm-wince\winceunits\
加入项目编译选项的第一行：-Fu里面，按确认却反而报错：
下面2套wince，是不是只需要一套就够了？
2008-08-04 03:01 9,472,480 fpc-2.2.2.arm-wince.exe //b
2009-12-13 10:08 36,295,445 fpc-2.2.4.i386-win32.exe //a
2009-10-25 17:44 14,772,181 Lazarus-0.9.28.2-fpc-2.2.4-cross-arm-wince-win32.exe //d
2009-10-25 17:37 64,580,088 lazarus-0.9.28.2-fpc-2.2.4-win32.exe //c
我是a、b、c、d都顺序安装了。。。。。。是不是安装重复了？
#20
WINCE用的ARM处理器，如果在PC上开发，应该先要做个交叉编译平台吧？
具体怎么弄就不知道了，这要慢慢去研究。
具体怎么弄就不知道了，这要慢慢去研究。
#21
另外在WINCE 这些嵌入式设备上开发，一般不直接用LCL库，太庞大了，
有个一专门的嵌入式可视库KOL-CE吧？编译后，非常小。
有个一专门的嵌入式可视库KOL-CE吧？编译后，非常小。
#22
lazarus下过、用过，不是很顺手，还是跟着delphi。
#23
用C#吧. 呵呵.我用起来觉得很顺手.
#24
友情up！
#25
vs老是用不惯。。。。。。。。而且也大，还需要.net高版本
#26
下了一个，还不知道怎么运行~
#27
前段时间研究过，有两个大问题使我不敢用它，
1.如楼主所说，速度太慢，特别是数值运算时，同样的程序要慢N倍，头疼啊。。。
2.BUG不少，比如楼上说的那个KOL-CE，莫名其妙报错，一报错，整个工程就无法使用了。
不过还是非常看好FPC，希望它越做越好
1.如楼主所说，速度太慢，特别是数值运算时，同样的程序要慢N倍，头疼啊。。。
2.BUG不少，比如楼上说的那个KOL-CE，莫名其妙报错，一报错，整个工程就无法使用了。
不过还是非常看好FPC，希望它越做越好
#28
不懂
#29
我覺得以前的做法是比較合適的。加紅字部份。你只是聲明了兩個變量，并沒有定義array[1..10] of integer是一個數據類型，所以arr,arr2不能相互賦值。這反映出來，delphi其實不是很“高級”。呵呵。
#30
据称国外的牛人研究出一个方法，让FPC可以为iPhone编写应用。其实也不奇怪，支持ARM的编译器都应该可以。
#31
楼主跟威锋网的sztony 有关系吗？同一个人？如果是，谢谢你之前破的英文字典~
#32
我只是来拿每天的10分
#33
严重同意
#34
其实现在看，还不如Python发展的好
#35
真是好东西！
#36
最近刚开始用delphi2010,先熟悉下。
#37
看看.
#38
下了试了下，竟然乱码
#39
同羡!
Lazarus没有Delphi手感好.
#40
支持。。。
#41
为什么编译后的EXE那么大？？？
#42
我在想，是不是新出的Delphi XE又落后了。。。
#43
默认什么都不做的空窗体都近12M了，通过加壳最小2M多吧，比delphi做的大多了。
#44
吼吼！佩服你呀！不做软件好多年，写东西还是那么专业！以前应该是个高手啊
#45
太恐怖了
#46
设置一下Lazarus的编译条件，就可以很小了，忘记是哪个设置，网上搜索一下，很多的
#47
楼主胡说八道，一看就是没什么了解的，就在那装深沉，最BS这种人！
#48
我更倾向于用Turbo Delphi，控件带源码的不安装，直接引用。界面都用基本界面。
#49
我曾多次接触过Lazarus，给我的感觉并没有期望的好，但我仍然很关心它的发展，当然最终取决于FPC的发展，毕竟除了Delphi外，它是Object PASCAL家族最大的希望了。如果将来FPC的效率、性能能够更好，那么建立在它之上的Lazarus会更有竞争力。
#50
Delphi没用过，Lazarus装过两次，一次winXP 32bit,一次Linux,哪次也没上手！可能是我学得东西还不够吧，毕竟一直是业余的，最多也就参加过一次NOIP，用gedit编写，在终端用FP + GCC编译也对付的过去。但好像Lazarus支持窗口！FPC怎么编才能有窗口啊，以前在windows里用TP，也只能在调试时用窗口，一旦正式编译后就不行了，有人知道吗？