[fpc-devel] what fpc is good for?

[Daniël Mantione]

Op Sat, 12 May 2007, schreef Bisma Jayadi:

> http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=3DMight%20As%20Well%20Use%20D=
ot%20Net%20In%20Place%20of%20FPC
> =

> Nicely put. ;) I've found it has good points on some arguments. It's good=
 to
> be considered. :)

No, it is not good to be considered. He complains we don't care about =

speed or size. I have to correct him: We care, if we can optimize =

something we will. As a proof FPC 2.2 will both generate faster code and =

generate smaller exes.

On the other hand, we consider the current situation unproblematic. FPC =

applications run faster, and less memory than other frameworks. Indeed we =

generate larger exes, but nobody needs to redistribute tens of megabytes =

of framework with his application. Lazarus is in the portable GUI =

market, not Win32. I fully agree Delphi is king for the Win32 GUI =

market. Against QT, XUL, Java, on the other hand, Lazarus is way better =

than each of them.

LCL applications are large, this is known, and something the Lazarus team =

has to deal with. Still, if you refuse to enable smartlinking, you have =

right to complain; those exes aren't 3MB if built properly.

But apparently the unsmartlinked size scares some people.There is a good =

solution to this perceived problem: make smartlinking good enough that it =

can be enabled always and remove the option not to smartlink. With the new =

internal linker we are almost there. Further, the internal linker will be =

able to smartlink unused virtual methods, reducing the size again. So, =

again you have nothing to complain about that we don't care.

If you don't consider FPC usefull for GUI programming, apparently he =

does't, the LCL disappears, and the problem disappears. No way you manage =

to generate 3MB exes without LCL.

If you want to do embedded programming, FPC is IMO totally suitable. You =

can nowdays even remove features like the heap from the system unit, how =

small do you want to go? But for such purpose you should not use large =

frameworks. I'm afraid asking that the ultra-comfortable frameworks =

generate embedded sizes is asking for the impossible. This is the error =

he makes: If you want the comfort of the framework: pay for it.

Nobody prevents you interfacing with databases directly, with GTK directly =

for teh GUI and so on. For embedded programming this is the way you should =

go, since there is no space for a database abstraction layer or GUI =

abstraction layer.

Meanwhile, we are near the top for speed, and at the top for memory usage:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=3Dall&lang=3Dall

Watch what happens with those numbers when 2.2 is out.

There is nothing in this article we can consider, for starters because it =

does not contain any proposals.

Dani=EBl