[fpc-devel] Forwarded message about FPC status

Sven Barth pascaldragon at googlemail.com
Mon Dec 17 10:55:24 CET 2012


Am 17.12.2012 10:36, schrieb Graeme Geldenhuys:
> It seems to me, main target of FPC development today is compatibility to
> the "modern" Delphi language constructs, I don't want to go this
> route.
And? Some people want to have these features (especially I want generic, 
I want helpers, I want closures and I want the extented RTTI, so I 
implement them!). If you don't need them, don't use them. We try to 
implement them in a way that the compiler's performance (parsing speed, 
etc.) or the executable size (to be implemented extended RTTI) is not 
influenced negatively too much. But somewhere one has to pay for it. 
Somewhen in the future we'll need to refactor the compiler a bit (maybe 
add multithreading support) and then things should be better again...

> And we need more flexibility, I can't fight days or weeks with
> Michael and Marco for every little change which is not on Lazarus or
> their own benefit.
I don't know what flexibility you are talking about, but including 
everything in the RTL is not the answer. One needs to judge what can be 
made part of it and what not, because otherwise it will just be a chaos 
(yes, it already is a bit, mostly because of backwards compatibility).

> Ouh, and there still is no unicode support for
> resource strings,
Currently not planned AFAIK. But maybe it's also not really necessary if 
the unit containing the resourcestrings is compiled in UTF8 format (I 
don't know though, this is not a topic I'm familiar with).
> no official statement how unicode will be implemented
> in RTL,
There is no official statement, because we don't know ourselves really 
where we want to go and everytime the discussions comes up it dies down 
a bit later without much results...
> the compiler becomes slower and slower,
I commented on this at the top already
> smart linking MSEide on
> 64 bit Linux is not possible with 2GB ram,
Linking is a problem of ld, not of Free Pascal. ld was not designed for 
the workload we put on it (especially regarding smart linking). You 
could try however if the new internal ELF linker solves this problem for 
you (I don't know whether it already supports smart linking; this is 
something that Sergei should answer)

> still no Delphi-like packages...
They are planned long term, but they are no cheesecake feature. We need 
to implement them in a way so that at least the major platforms 
(Windows, Linux, Mac OS X) can make use of it and already the difference 
regarding procedure name resolution between Windows and Unix can cause 
headaches...

Regards,
Sven



More information about the fpc-devel mailing list