On 09/11/2011 07:33 PM, Hans-Peter Diettrich wrote:
No Latex support here (Win7)
Virtual Box is your friend :-) .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/12/2011 12:18 PM, Hans-Peter Diettrich wrote:
I'd add another 100€ for reasonable debugging support in Lazarus :-)
Could you generate a wish-List ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/
On 09/12/2011 12:10 PM, Graeme Geldenhuys wrote:
- watchpoints. break when data at memory address changed. Very
handy to debug those procedural programs that loves to use global
variables. MSEide supports this (but it is actually a GDB feature)
Ooops. (Without hardware support) This
On 09/12/2011 01:15 PM, Martin Schreiber wrote:
gdb uses hardware watchpoint support if available.
That seems hard to beat when doing a new multi-arch debugger
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freep
On 09/12/2011 11:16 PM, Hans-Peter Diettrich wrote:
- watchpoints. break when data at memory address changed.
I've seen applications crawl when such a feature was used :-(
This is bound to happen unless the CPU provides support for this. (I
have no idea which of the CPUs supported by FPC ha
On 09/12/2011 11:51 PM, Hans-Peter Diettrich wrote:
) debugger, I only want *better* high-level (language specific)
support in Lazarus. Finally I want to debug applications, not an new
debugger with different behaviour and restrictions on every platform ;-)
A multi-arch compiler should come with
On 09/12/2011 03:23 PM, r...@rdos.net wrote:
that does not have a modern GUI integrated into it,
Why should a debugger have it's own GUI ? IMHO it should be used
integrated in an IDE, so tit should have a decent API to be used by an IDE.
So providing a command line interface (if started sitt
On 09/13/2011 11:06 AM, Jonas Maebe wrote:
GDB is built for supporting multiple languages. E.g., its ADA support
has been much better than its C++ support for a long time (although
C++ support is getting fairly good nowadays too).
Unfortunately it seems to be hard (or close to impossible) to w
On 09/13/2011 01:22 PM, Jonas Maebe wrote:
Don't insult people when you clearly don't have any experience
whatsoever in working with them.
Sorry if I sounded impolite. I did not at all mean to insult them. On
the contrary I praise them for their exceptional work !
I only wanted to state that
On 09/13/2011 02:09 PM, Joost van der Sluis wrote:
Very well said !
Thanks,
-Michael (who does a lot more ANSI C than Pascal, as this is necessary
with embedded controllers.)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.fre
Sounds good !
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 09/13/2011 04:52 PM, Hans-Peter Diettrich wrote:
It's not the CPU, it's more the MMU which can help in finding changed
(global) variables.
AFAIK, the MMU can not work in byte addresses but just with much bigger
blocks of data. So it does not seem to help with finding a write access
to a de
On 09/13/2011 02:53 PM, Joost van der Sluis wrote:
You do know that GDB does have a Pascal extension, right?
IMHO, if we really can work with the gdb team on feeding the necessary
Object-Pascal specific add-ons into gdb, creating a new debugger from
scratch does not make any sense at all.
-Mi
On 09/13/2011 04:59 PM, Hans-Peter Diettrich wrote:
IMO you're addressing the wrong audience. Most things, beyond
breakpoint handling, stepping and memory read/writes, can be done
outside the debugger. Such external code is not bound to debugger
support, and can use language specific informat
On 09/14/2011 08:50 AM, Felipe Monteiro de Carvalho wrote:
All Linux distributions that I know use utf-8
Android uses utf-8
Meego uses utf-8
AFAIK, the EXT system does not care about the code the file-name
byte-arrays are done in. only 0x00 (end of name) and '\' are interpreted.
-Michael
___
On 09/14/2011 01:01 PM, Michael Schnell wrote:
AFAIK, the EXT system does not care about the code the file-name
byte-arrays are done in. only 0x00 (end of name) and '\' are interpreted.
Sorry, (typing too fast again)
Only 0x00 (end of name) and '/' are interpreted
On 09/14/2011 10:51 AM, Felipe Monteiro de Carvalho wrote:
In this case then for sure we cannot only have file routines only in
UTF-16, because that would make it impossible to identify many files
in Linux...
Who says that file names are supposed to be human readable and this done
in some charac
On 09/14/2011 11:05 AM, Marco van de Voort wrote:
First and for all. Backwards compat dropping is not going to happen.
It already has and supposedly can't be avoided. Take a look of what
Lazarus was forced to make out of the identity of ANSIString and
UTF8String seemingly forced by FPC. e.g.:
On 09/14/2011 01:58 PM, Sven Barth wrote:
But the debugger can ask the OS to write protect a page or to enable a
page guard (which triggers on write access) and then the corresponding
signal/exception can be catched. This reduces the checks necessary
from the complete process memory down to o
On 09/14/2011 09:00 PM, Hans-Peter Diettrich wrote:
Every (reasonable) OS provides such features in its debug API.
Available support depends on the actual hardware, of course.
Can you point us to a description (Win XP, Win 7, Linux ?)
Thanks,
-Michael
___
On 09/14/2011 08:47 PM, dmitry boyarintsev wrote:
That's true. The only thing concerns me about that, is there's no
really a standard in GDB (i can be wrong).
This of course would be a necessary condition for working with the gdb team.
Also, IRC, Apple forked gdb (as well other gnu-tools) to
On 09/14/2011 05:02 PM, Hans-Peter Diettrich wrote:
The NT WinAPI (not 9x) *implements* everything in the Wide (UTF-16)
routines
without reference-counting: Yak !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freep
On 09/14/2011 05:02 PM, Hans-Peter Diettrich wrote:
The NT filesystems store names in UTF-16, while Unix filesystems store
UTF-8.
there are lots of file systems in Linux. They can work differently. i.e.
FAT works case insensitive while ext* works cases sensitive. IMHO ext
completely ignores
On 09/14/2011 05:02 PM, Hans-Peter Diettrich wrote:
But let's not forget the user!
Many users still want simple string handling, with direct mapping
between logical and physical chars (SBCS).
This is why new Delphi versions provide "New Strings" that know about
thee coding their content is
On 09/14/2011 05:19 PM, Hans-Peter Diettrich wrote:
Can you specify, *which* strings ever *require* platform specific
encoding?
If not strings, Chars do:
MyString := 'Öse';
MyChar := MyString[1];
-Michael
___
fpc-devel maillist - fpc-devel@list
On 09/14/2011 07:24 PM, Hans-Peter Diettrich wrote:
Unicode users have no use for an char type, instead they have to use
substrings for every logical character.
Yep.
The problem is that a "normal" programmer (especially a beginner) does
not know (and does not want to know, and IMHO should not
On 09/15/2011 09:57 AM, Graeme Geldenhuys wrote:
What the hell has "experience" got to do with the preference between
UTF-8 and UTF-16?
In fact users want to deal with "decently coded characters" and not with
"cryptic bytes some of which together are representing a character".
(e.g. when d
On 09/15/2011 10:39 AM, Graeme Geldenhuys wrote:
MyChar := UTF8Copy(MyString, 1, 1);
The above example is safe,
Of course. But generations of Pascal programmers have been trained to do
MyChar := MyString[1];
So it would at least be candid to abolish the String[i] notation as a
syntax fe
On 09/15/2011 10:43 AM, cobines wrote:
MyChar := MyString[1]
appropriate function retrieves first unicode character, regardless of encoding.
MyChar is an 8 bit thingy and thus is not even able to hold a Unicode
'ä' (in what ever UTF).
-Michael
___
On 09/15/2011 11:08 AM, Graeme Geldenhuys wrote:
+1 on both counts.
Hoping for complex things to automatically be solved by just ignoring
the complexity usually leads into hell.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
htt
On 09/15/2011 11:06 AM, Graeme Geldenhuys wrote:
and to show you AGAIN how flawed your "direct index access to a
character" example is.
It's not "my" intend to use it. I'll never use it as I do know that it
is bound to create problems. But it is what generations of pascal
programmers are train
On 09/14/2011 07:24 PM, Hans-Peter Diettrich wrote:
Unicode users have no use for an char type, instead they have to use
substrings for every logical character.
"Unicode" is 32 Bis and allowing for (nearly) any supported character.
So a 32 Bit UnicodeCharacter in fact is very viable.
-Michael
On 09/15/2011 11:40 AM, cobines wrote:
Such people should retrain if they want to switch to Unicode using
some instructions how to convert your application.
In fact they don't know about Unicode and thus don't even know that they
need training :-) .
If they do not
want, they should stay with A
On 09/15/2011 11:43 AM, Martin wrote:
Which imho makes utf8 far more preferable than utf16
in UTF8 the error is bound to happen
ROFL.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fp
On 09/15/2011 12:41 PM, cobines wrote:
I don't know if in Delphi you can use just Ansi,
Delphi is a completely different matter as (by default) old versions use
ANSI and new versions use Unicode in NewDelphiStrins with dynamic encoding.
-Michael
___
On 09/15/2011 01:26 PM, cobines wrote:
I see. Then people switching from Delphi/Ansi to Lazarus/UTF-8 will
have problems if they are not aware they have to adjust their
applications.
Switching from Lazarus-pre-Unicode, Delphi pre-Unicode and
Delphi-Unicode will cause this problems (for not comp
On 09/16/2011 07:33 AM, cobines wrote:
I understand that argument is not "easier to learn" but "easier to
transition to from Ansi if you don't care to learn".
ANSI means: each element you get is a character.
With Unicode this is only (close to) true when using a 32 Bit encoding.
When using 8
On 09/15/2011 07:39 PM, Hans-Peter Diettrich wrote:
Only when an application must *interpret* strings in foreign languages,
With UTF-8 German is such a foreign language :(
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://list
On 09/15/2011 09:07 PM, Felipe Monteiro de Carvalho wrote:
Well, I think the RTL should introduce a TStringsUTF8 at the very
least.
and/or (better ?!? ) introduce a basic string type name TStringUTF8.
I understand that cpstrnew is at least considered on the long run.
Is migrating to multiple s
On 09/16/2011 07:36 AM, cobines wrote:
Currently UTF8String is just an alias for AnsiString,
Which obviously is bound to produce a lot of confusion UTF-8 code in a
thing explicitly called "ANSIString" ???
-Michael
___
fpc-devel maillist - fpc-deve
On 09/15/2011 09:01 PM, Hans-Peter Diettrich wrote:
FPC also allows to use Complex values - but nobody is forced to use
such numbers
German (and French end, ...) Lazarus programmers are Forced to deal with
Unicode if the accept user input. (Newer versions of) Lazarus can't be
set to work in
On 09/15/2011 09:07 PM, Felipe Monteiro de Carvalho wrote:
Well, I think the RTL should introduce a TStringsUTF8 at the very
least.
and/or (better ?!? ) introduce a basic string type name TStringUTF8.
I understand that cpstrnew is at least considered on the long run.
Is migrating to multiple s
On 09/19/2011 11:13 AM, Marco van de Voort wrote:
No. IMHO the point has always been to find a sweet spot. Delphi is not
Visual Basic. Delphi is native and fast.
Isn't this nicely provided by "new Strings" ?
If you are naive and just use them as you have been acquainted to at
ANSI times, your
On 09/18/2011 05:52 PM, Marco van de Voort wrote:
And of course, finally, there is the matter with Delphi compatibility.
This can't even be discussed regarding Unicode programming as long as
FPC does not have "new Strings".
(AFAIK there even are or have been discussions about not doing new
s
On 09/18/2011 06:49 PM, DaWorm wrote:
But isn't it O(n^2) only when actually using unicode strings?
Allowing the compiler or library decide _if_ this is a Unicode string
would require either a dedicated sting types for each encoding or "New
Strings" with programmable encoding.
-Michael
__
On 08/05/2011 09:47 PM, Marcus Sackrow wrote:
...
Hi Marcus,.
Any progress ?
I understand that for Amiga you need an 68 K (cross compiler) version
of FPC.
I'd be interested in same, as well.
Any progress here?
___
fpc-devel maillist - fpc-dev
On 09/26/2011 03:21 PM, Sven Barth wrote:
Pre-4.x versions of AmigaOS supported 68k, newer ones support only
PowerPC. Also AROS seems to be mainly based on x86 and PowerPC (a port
to 68k exists though). So 68k does not seem to be necessary.
So I seem to be out of luck :( :)
-Michael
___
On 10/03/2011 11:41 AM, michael.vancann...@wisa.be wrote:
Currently, hard work is being put in the unicode string and codepage
string
routines in the RTL.
Do I understand correctly that this is the "New String" string handling
(to be optionally, by default or exclusively used) ?
Do I und
On 10/04/2011 10:59 AM, Michael Van Canneyt wrote:
Yes. Each string will have a codepage identifier associated with it.
if, during an assign operation, a difference exists, a conversion will
occur.
(there are of course some exceptions)
GREAT !
I wonder when Lazarus will be able to follow an
On 10/04/2011 11:59 AM, Sven Barth wrote:
The earliest point is when the next big release after 2.6 is released
(note: I don't mean 2.6.x here, more a 2.8). As 2.6 is currently
prepared you can estimate how long that will take.
I see. ;-)
Unfortunately Delphi is way ahead on this behalf, b
On 10/04/2011 01:02 PM, Hans-Peter Diettrich wrote:
I wonder when Lazarus will be able to follow and use this string type
for the complete library.
The LCL will use one unique encoding, most probably UTF-8 as the only
losless Unicode representation. This means that strings with different
e
I understand that Lazarus will not be able to run with the "NewString"
version of FPC.
Semmingly it can't even be compiled.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 10/10/2011 10:35 AM, Paul Ishenin wrote:
Strange logic. How you decided that if something does not do now it
will not be able to do the same at future.
I understand that the type "String" will change it's behavior (please
correct me if I'm wrong).
I understand that Lazarus might use assumpt
I suppose there is a way to just set the encoding of a new string. This
should not affect the stored bytes (or words or DWords).
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 10/10/2011 10:11 PM, Luiz Americo Pereira Camara wrote:
2- It should have (dont know if currently has) a compiler switch to
change the default code page to UTF8 or whatever, so all variables
with type String will map to UTF8String.
Why ?
I feel, the LCL code should only be codepage aware
On 10/10/2011 11:11 PM, Martin wrote:
But that will always just push the issue to another location.
Somewhere the change from string to utf8string must be made.
??? The "new string" paradigm is all about changing from utf8string (and
other such types) to string. Isn't it ?
The big decision wa
On 10/11/2011 12:23 AM, Martin wrote:
Utf8ToLower is, (and should) be declared expecting a Utf8String.
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
With dynamically encoded Strings "ToLower" should work for any encoding.
-Michael
_
On 10/11/2011 08:52 AM, Hans-Peter Diettrich wrote:
It does *not* help, because SetCodePage does a string *conversion*,
when it really changes the encoding.
That of course does make sense. OTOH, there should (must) be a function
that forces the encoding to some setting without looking at the
On 10/11/2011 09:17 AM, Hans-Peter Diettrich wrote:
IMO Lazarus (and FPC) should follow the Delphi way, with strictly
separate Unicode and pre-Unicode versions. Nobody can expect that new
VCL (Unicode) components can be back-ported to Ansi versions.
As right now the current (Unicode aware) L
On 10/11/2011 07:33 AM, Hans-Peter Diettrich wrote:
I'd use another type, e.g. LCLstring, which can be set independently
from any other automatisms.
While using a "private" string type "just in case" or for flexibility in
a work in progress, might be a good idea, the goal should be to
every
On 10/11/2011 07:33 AM, Hans-Peter Diettrich wrote:
Concrete types are required when strings are manipulated (parsed...),
and the implementation assumes a certain encoding.
Why do you think so. when parsing, a 32 bit Unicode character can be
extracted from a new string with any (not raw) encod
On 10/11/2011 11:20 AM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Why should a function Utf8ToLower be used (or even be defined for
normal use) ?
Because it expects and UTF8 argument, and provides an UTF8 result, so
that no further conversions are required when used with strings
On 10/11/2011 11:28 AM, Hans-Peter Diettrich wrote:
Excessive use of RawByteString is at least as inefficient as using
Variant for everything :-(
While I still doubt that (only) RawByteString is a type that is to be
used for dynamical encoding
That is correct, depending on what exces
On 10/11/2011 11:05 AM, Marco van de Voort wrote:
In our previous episode, Michael Schnell said:
I suppose there is a way to just set the encoding of a new string. This
should not affect the stored bytes (or words or DWords).
Afaik it does, but only for ansistring.
What exactly is "ansis
On 10/11/2011 11:05 AM, Marco van de Voort wrote:
IRC there is also a codepage that
just means "system default" and assumes the system knows how to convert that
from/to utf16 (or utf8 on *nix)
Why should it do a _conversion_ and not just use the appropriate coding
(e.g. utf-16 on Windows and ut
On 10/11/2011 11:30 AM, Paul Ishenin wrote:
11.10.2011 16:52, Michael Schnell wrote:
In fact I still don't understand the difference between a type called
"RawByteString"and a basic new String that happens to be set to the
encoding "RawByte".
Encoding RawByte as w
On 10/11/2011 08:52 AM, Hans-Peter Diettrich wrote:
It does *not* help, because SetCodePage does a string *conversion*,
Nope.
procedure SetCodePage(var s : RawByteString; CodePage : TSystemCodePage;
Convert : Boolean = True);
So it can be set to do a conversion or not to do it.
-Michael
__
On 10/11/2011 10:11 PM, Hans-Peter Diettrich wrote:
(a) Sorry, but this does not answer the question I tried to ask
(Difference between a possible type called RawByteString and a basic
"new string" variable that happens to be set to the Encoding ID
"RawByte").
When I have a variable of type
On 10/11/2011 09:37 PM, Hans-Peter Diettrich wrote:
Why implement the upper/lower translation N times, when afterwards the
N encodings have to be converted into the Result encoding? Where the
encoding conversions already exist...
Obviously, the dedicated upper/lower translation done in a certa
On 10/11/2011 09:37 PM, Hans-Peter Diettrich wrote:
IMO, calling ToLower with a string that is set to the encoding
"RawByte" does not make sense and should generate an exception.
Nope.
A new string consists of a record that contains the encoding ID, element
size, reference count, length and
The last answer was to
On 10/11/2011 09:37 PM, Hans-Peter Diettrich wrote:
When a string is assigned to an RawByteString, both point to the
original string, which has a valid (non-raw) encoding.
-Michael
___
fpc-devel maillist - fpc-devel@lists.
On 10/12/2011 10:09 AM, Paul Ishenin wrote:
12.10.2011 16:03, Michael Schnell wrote:
I suppose a variable of the type "String" is pre-loaded with the
predefined "System" encoding ID.
If you mean "AnsiString" then it is loaded with encoding 0 which means
defaul
On 10/12/2011 10:35 AM, Sven Barth wrote:
No. In Delphi "String = UnicodeString", but AnsiString still exists as
a one-byte (or multi-byte) string type (the "new string type" or "code
page aware string type").
Sorry, but I don't understand.
According to the "TAnsiRec", such a "New String" no
On 10/12/2011 01:53 PM, Hans-Peter Diettrich wrote:
All AnsiString types have an element size of 1, UnicodeString has 2
and UCS4String has 4 bytes per element.
Disregarding whether or not this makes sense: what technology enforces
this (e.g. Compiler Magic or RTL) ?
-Michael
On 10/12/2011 01:45 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
So target encoding ID "0" means that " := " will preserve the
encoding of the source and set the target appropriately without doing
a conversion.
No. Codepage 0 stands for the system encodi
On 10/12/2011 12:13 PM, Hans-Peter Diettrich wrote:
Delphi allows for RawByteStrings with encoding 0. When assigned to an
AnsiString, the string encoding still is zero, both variables seem to
point to the same string data.
The pointing to the data array (managed by "lazy copy and reference
On 10/12/2011 12:09 PM, Hans-Peter Diettrich wrote:
Seemingly (other than I assumed) a " := " between new strings does
not preserve the encoding, but performs an encoding conversion to the
target's encoding ID.
Right.
As I now understand: Exception: Target encoding ID = 0, source encoding
On 10/12/2011 12:09 PM, Hans-Peter Diettrich wrote:
Right, the new string types are *strict* types,
That does make sense regarding Pascal's general "strict type" paradigm.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://list
On 10/12/2011 02:09 PM, Sven Barth wrote:
Basically both, as both rely on and use the fact that "AnsiString[i] =
AnsiChar" and "SizeOf(AnsiChar) = 1" and also "UnicodeString[i] =
UnicodeChar" and "SizeOf(UnicodeChar) = 2".
Yep.
But what I wanted to ask is what happens, if I disregard this, e
On 10/12/2011 02:17 PM, Sven Barth wrote:
The pointing to the data array (managed by "lazy copy and reference
counting features) is independent from the encoding ID, that is part of
the string management record and not of the data array.
Wrong. Both reference counting and code page are part o
On 10/12/2011 02:28 PM, Sven Barth wrote:
There will be a conversion.
Meaning:
- when it is a var parameter, am error message is issued.
- when it is a value parameter: conversion is called
- type cast will do a conversion
- assignment will do a conversion (at least if the target encoding
On 10/12/2011 11:45 AM, Sven Barth wrote:
RawByteString is special, because any other string can be assigned to
it WITHOUT conversion, but the code page of the assigned string will
be kept, so one can still check which code page the original string had.
Ooops, so there is not encoding ID "RA
On 10/12/2011 11:33 AM, Alex Shishkin wrote:
...
While I feel that something like this migh be a(nother) decent way to
handle Unicode strings, obviously different decisions have been taken
because
1) Pascal is supposed to be a strictly typed language. This asks for
being able to use distinct
In fact this seems to avoid the "nice" feature of the current
(Delphi-like) Implementation.
Here seemingly inconsistent (or rather "intersexual") strings are
provided for: perfectly encoded and distinguishable data that suffers
from being locked in a variable that happens to be of a type with
On 10/12/2011 02:39 PM, Sven Barth wrote:
I'd say yes (the only point I'm really unsure about is "var"-arguments).
I did this list according to what I expect regarding to different
numerical types (like integer and real) or two really different string
types (like short string and long string)
On 10/12/2011 04:23 PM, Sven Barth wrote:
There was some discussion about how to handle var parameters, but I
don't remember the outcome anymore. AFAIK Delphi issues a compile
error (I don't know for sure though).
Options are:
- compiler error
- compiler warning
- runtime exception
- con
Thanks !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 10/13/2011 02:16 AM, Hans-Peter Diettrich wrote:
Almost every required conversion can be determined at compile time.
It also _can_ be determined at runtime according to the current encoding
ID of the string(s)
This discussion is not about "can" but about "is" and maybe "should be".
Moreov
On 10/13/2011 02:05 AM, Hans-Peter Diettrich wrote:
- assignment will do a conversion (at least if the target encoding
ID is not zero.)
... conversion unless the target type is RawByteString, or has the
same encoding.
Paul did inform us that encoding ID = 0 in the target means no
conversion
On 10/13/2011 04:27 AM, Hans-Peter Diettrich wrote:
FireMonkey is a third-party product, now bought by Embarcadero. That
deal seems to be an attempt to avoid an own development, what already
failed with both Kylix and Delphi.NET.
instead of Kylix they now with XE2 provide FPC and instead of Delp
On 10/13/2011 04:27 AM, Hans-Peter Diettrich wrote:
I don't see a speed penalty in using UTF-16. In contrast to UTF-8 it
simplifies (and consequently speeds up) all string handling.
If doing code heavily doing GUI handling (such as the LCL in Lazarus)
and the GUI's API is not UTF-16, all str
On 10/13/2011 10:11 AM, Marco van de Voort wrote:
No, they stated the FPC usage was only temporary because their own ARM
compiler was delayed.
but AFAIK not notion on until when
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
ht
On 10/13/2011 03:13 AM, Hans-Peter Diettrich wrote:
..., or try to implement something incompatible with Delphi :-(
I would not generally depreciate this.
I heard a lot comments on problems introduced by the Delphi Unicode
String implementation. So maybe in fact there is room for (incompatibl
On 10/13/2011 08:20 AM, Paul Ishenin wrote:
RawByteString codepage. Value $ and purpose - inform that string
has no codepage assigned. I think at the moment compiler does not
produce strings of codepage $ anymore but before it did. So now we
can probably clear the RTL from this codepa
On 10/13/2011 09:43 AM, Sven Barth wrote:
1. Currently there is this huge work going on to get trunk to a
reasonable and usable shape again and until that is done (and maybe
RTL changes as well) it is (in my opinion (!) ) not reasonable to
think about changing the meaning of "string" at all.
On 10/13/2011 09:47 AM, Sven Barth wrote:
Since FPC 2.4 there also is a UnicodeString in FPC which is compatible
to the one in Delphi: a reference counted 2-byte-per-character string
type.
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
-Michael
__
On 10/13/2011 10:39 AM, Sven Barth wrote:
When installing you can always select a custom directory though you
can not change the version-id. E.g. you could install to
"/lib/fpc-cpstring/2.7.1".
Of course I do know how to install FPC in another directory or how to
preserve the current installa
On 10/13/2011 10:52 AM, Sven Barth wrote:
So you suggest that in Delphi XE, UnicodeString is _not_ a "new String"
Type ?
I don't know what you describe as "new string", but "UnicodeString"
was introduced as a new type in Delphi 2009 and "String" was made an
alias to "UnicodeString". If you
On 10/13/2011 11:05 AM, Mattias Gaertner wrote:
LCL backends work in UTF-16.
Of course the LCL backends close to the OS-API on Windows use UTF-16, as
this is what the API provides. (Or did I misunderstand your wording ?)
-Michael
___
fpc-devel mail
On 10/13/2011 11:19 AM, Sven Barth wrote:
No, UnicodeString is not codepage aware.
I was asking about the implementation in XE.
If you mean this: Thanks for the clarification.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://
1 - 100 of 1899 matches
Mail list logo
