[fpc-devel] Forwarded message about FPC status
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
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
More information about the fpc-devel