On Mon, Nov 8, 2010 at 10:32 PM, Joost van der Sluis jo...@cnoc.nl wrote:
Hmm... r15671 which fixes this issue, is not merged to the release.
So to fix this, you have to apply r15671 from trunk to fpcsrc, before
you build the rpm. (I did so for the Fedora rpm's)
Just to be sure, the command
But it might be an advantage for some projects as the discussions over
the years implied.
What about using GC for fpc itself? If it is usable for fpc, then the
problem of fpc leaking memory when compilation fails with errors can be
solved using GC. As a result fpc can be integrated to some
On 11/18/2010 08:05 AM, Thaddy wrote:
To summarize: what you write/propose is already in there :)
OK, great, its there, but how to get it _here_ ?
To make it useful FPC would need some the appropriate keywords (such as
GarbageControlled) for creating this type of variables, and it would
On 11/18/2010 12:33 AM, Hans-Peter Diettrich wrote:
Separator characters can be assumed as ASCII, so that they can be
found by a dumb byte/char scan; only few encodings have to be
recognized and handled, based on the char size: MBCS (UTF-8...),
WideChars (UTF-16/UCS2) and UTF-32.
In fact I
In our previous episode, Michael Schnell said:
found by a dumb byte/char scan; only few encodings have to be
recognized and handled, based on the char size: MBCS (UTF-8...),
WideChars (UTF-16/UCS2) and UTF-32.
In fact I suppose that for UTF-8 (pure UTF-8 without surrogates) pos()
On 11/18/2010 02:31 PM, Marco van de Voort wrote:
Either you have UTF-8 with surrogates, or you have ASCII (since UTF-8
without surrogates means that only char 0..127 are valid, which is ASCII)
In another post surrogate pairs have been denoted as a specialty of a 16
Bit coding (UCS-2), and I
In our previous episode, Michael Schnell said:
Either you have UTF-8 with surrogates, or you have ASCII (since UTF-8
without surrogates means that only char 0..127 are valid, which is ASCII)
In another post surrogate pairs have been denoted as a specialty of a 16
Bit coding (UCS-2), and I
Hi all,
I'm converting a Delphi 2009 project to FPC. In this project all strings are
widestrings, which is default for Delphi 2009. However, in FPC all strings are
still 'normal' strings. Is there a way (compiler switch?) to use widestring as
default for all strings in FPC?
Kind regards,
18.11.2010 21:12, Birger Jansen wrote:
Hi all,
I'm converting a Delphi 2009 project to FPC. In this project all strings are
widestrings, which is default for Delphi 2009. However, in FPC all strings are
still 'normal' strings. Is there a way (compiler switch?) to use widestring as
default
On 18 Nov 2010, at 15:12, Birger Jansen wrote:
I'm converting a Delphi 2009 project to FPC. In this project all
strings are widestrings, which is default for Delphi 2009. However,
in FPC all strings are still 'normal' strings. Is there a way
(compiler switch?) to use widestring as default
On 18-11-2010 13:21, Z(ilvinas Ledas wrote:
But it might be an advantage for some projects as the discussions
over the years implied.
What about using GC for fpc itself? If it is usable for fpc, then the
problem of fpc leaking memory when compilation fails with errors can
be solved using GC.
Hi,
There could be native Datatypes, that means data types that are
compiled into fastest code by compiler (without size casting). An
example is the PtrInt, but there should a more intuirive naming:
- BestInt (integer in system size)
- BestFloat (float that is calculated fastest)
-
Keep in mind that Delphi 2009's default string type is much more than
a regular widestring. Using unicodestring instead in FPC would be
more correct, but even then you won't have the same support yet (that
first requires the completion of the cpstrnew branch, as Paul
indicated).
13 matches
Mail list logo
