Sven Barth schrieb:
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record.
No, they
On 10/13/2011 02:36 PM, Marco van de Voort wrote:
Afaik tansirec (d2009 style)=tunicoderec (d2009) style.
The rawbytestring type afaik depends on that,
According to Embarcadero: "RawByteString type is type ANSIString($)"
So the implemented structure of RawByteString and ANSIString obvious
13.10.2011 16:31, Sven Barth пишет:
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling rec
In our previous episode, Michael Schnell said:
> >
> > No, they have something else like TUnicodeRec or so.
> >
> Which does not provide a CodePage element ???
Afaik tansirec (d2009 style)=tunicoderec (d2009) style.
The rawbytestring type afaik depends on that, that any string can be passed
to it
On 10/13/2011 02:31 PM, Sven Barth wrote:
No, they have something else like TUnicodeRec or so.
Which does not provide a CodePage element ???
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listi
Am 13.10.2011 14:35, schrieb Michael Schnell:
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record.
No, they have something else l
On 10/13/2011 02:08 PM, Hans-Peter Diettrich wrote:
but you cannot derive further types with different encoding from it,
as you can do from AnsiString.
I see. So these variables don't have a TAnsiRec handling record.
Thanks,
-Michael
___
fpc-devel ma
Michael Schnell schrieb:
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
On 10/13/2011 01:45 PM, Luiz Americo Pereira Camara wrote:
This means that StringCodePage is only meaningful when calling it on a
string variable that actually holds a string.
How can a string variable not hold a string ? It might hold an empty
string, but what is a "no-string" ?
Of course
On 10/13/2011 02:16 AM, Hans-Peter Diettrich wrote:
Almost every required conversion can be determined at compile time.
The only uncertain case is a result (or other source) of type
RawByteString.
What should be the point in doing a library supporting Strings with
dynamically (at run-time)
On 13/10/2011 04:55, Michael Schnell wrote:
On 10/13/2011 02:05 AM, Hans-Peter Diettrich wrote:
There is no "Raw" source ID.
The Delphi doc says "the RawByteString Type is type ANSIString($)".
So the RawByte encoding ID in fact is $ (if FPC wants to be Delphi
compatible in that behal
Marco van de Voort schrieb:
In our previous episode, Michael Schnell said:
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 Delphi.NET
they sell Prism. Both are 3rd party pr
Paul Ishenin schrieb:
What's CP_NONE? Value and purpose?
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 f
On 13 Oct 2011, at 11:37, Felipe Monteiro de Carvalho wrote:
Carbon and Cocoa are rather encoding agnostic, but from what I
understand they use UTF-8 internally.
It's not documented what they use internally, but since all CFString
(= NSString) "character" accessors are UTF-16 based, I think
On Thu, Oct 13, 2011 at 11:26 AM, Sven Barth
wrote:
> AFAIK it was remarked that Qt and Carbon (or only Cocoa?) use UTF-16 as
> well.
Carbon and Cocoa are rather encoding agnostic, but from what I
understand they use UTF-8 internally.
Qt is also rather agnostic, but internally I think it uses UT
Am 13.10.2011 11:29, schrieb Michael Schnell:
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.
Yes, I meant this. Only AnsiString is code page aware in Delphi 2009+
Am 13.10.2011 11:27, schrieb Michael Schnell:
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 ?)
AFAIK it was remarked th
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://
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
Am 13.10.2011 11:04, schrieb Michael Schnell:
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"
Michael Schnell hat am 13. Oktober 2011 um 10:18
geschrieben:
> 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 G
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
Am 13.10.2011 10:46, schrieb Michael Schnell:
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
Am 13.10.2011 10:34, schrieb Alex Shishkin:
13.10.2011 11:30, Sven Barth пишет:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
va
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
__
13.10.2011 11:30, Sven Barth пишет:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
variable names etc can all contain Unicode text
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 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 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 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
In our previous episode, Michael Schnell said:
> > 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 Delphi.NET
> they sell Prism. Both are 3rd party products, too.
No, t
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
Am 13.10.2011 09:56, schrieb Jonas Maebe:
On 13 Oct 2011, at 09:30, Sven Barth wrote:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Perhaps it's an attempt to better interface with .NET, Java or
ObjectiveC?
I don't think so as AFAIK all three don't support unicode characters
in identif
On 13 Oct 2011, at 09:30, Sven Barth wrote:
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Perhaps it's an attempt to better interface with .NET, Java or
ObjectiveC?
I don't think so as AFAIK all three don't support unicode characters
in identifiers.
Java does, but the JDK doesn't c
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
Am 13.10.2011 09:49, schrieb Michael Schnell:
Moreover seemingly there is (or will be, or in Delphi XE is) a type
called UnicodeString. In the Delphi docs UnicodeString is said to be
supposed to hold UTF-16 encoded data. But this of course is due to the
string Windows-Binding of Delphi. On Linux
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
Am 13.10.2011 04:30, schrieb Hans-Peter Diettrich:
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
variable names etc can all contain Unicode text in there names. So yes,
Unicode is r
13.10.2011 14:57, Hans-Peter Diettrich пишет:
Paul Ishenin schrieb:
13.10.2011 9:13, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/astrings.inc?revision=19444&view=markup
I don't understand the use of encoding 0 and CP_NONE in F
Paul Ishenin schrieb:
13.10.2011 9:13, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/astrings.inc?revision=19444&view=markup
I don't understand the use of encoding 0 and CP_NONE in FPC. Can
somebody explain?
DefaultSystemCodep
13.10.2011 9:13, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/astrings.inc?revision=19444&view=markup
I don't understand the use of encoding 0 and CP_NONE in FPC. Can
somebody explain?
DefaultSystemCodepage is used When the pati
Martin Schreiber schrieb:
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
variable names etc can all contain Unicode text in there names. So yes,
Unicode is required throughout the Object Pascal language, and F
Graeme Geldenhuys schrieb:
On 12/10/2011 11:47, Martin Schreiber wrote:
idea. Have a look at Firemonkey and you know what I mean. ;-)
For those unfamiliar with Firemonkey, would you mind explaining further.
...but over all, I do agree with your statement, that FPC shouldn't
follow Delphi bli
Sven Barth schrieb:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/astrings.inc?revision=19444&view=markup
I don't understand the use of encoding 0 and CP_NONE in FPC. Can
somebody explain?
Furthermore I suspect that the implementation of
Function Pos(Const Substr : RawByteStri
Michael Schnell schrieb:
In fact the var parameter case is most interesting regarding new strings.
While in the other cases the system can decide at runtime what do do
(with respect to the encoding ID (s) ), with a var parameter the type
names might be used to generate an error message at com
Michael Schnell schrieb:
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
Correct, so far.
- assignment will do
On Wednesday 12 October 2011 14.32:38 Jonas Maebe wrote:
> On 12 Oct 2011, at 14:17, Graeme Geldenhuys wrote:
> > eg: UTF-8 as native string type under *nix systems, and
> > UTF-16 under Windows. Why must some platforms get a speed penalty and
> > others not, when you force only one encoding on all
Thanks !
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 12.10.2011 16:46, schrieb Michael Schnell:
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
- c
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
Am 12.10.2011 15:35, schrieb Michael Schnell:
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 str
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 12/10/2011 14:38, Martin Schreiber wrote:
>
> Read here for example:
Thanks for the link.
> Is this desirable? What is the benefit of non ASCII Pascal identifiers at the
> expense of performance and simplicity?
No idea if it is desirable - probably not, when it is a global open
source proj
Am 12.10.2011 14:16, schrieb Michael Schnell:
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
Am 12.10.2011 14:40, schrieb Michael Schnell:
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 co
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 Wednesday 12 October 2011 14.17:57 Graeme Geldenhuys wrote:
>For those unfamiliar with Firemonkey, would you mind explaining further.
Read here for example:
https://forums.embarcadero.com/forum.jspa?forumID=380
> As for you statement regarding "do we need Unicode support everywhere?"
> Well
On 12 Oct 2011, at 14:17, Graeme Geldenhuys wrote:
eg: UTF-8 as native string type under *nix systems, and
UTF-16 under Windows. Why must some platforms get a speed penalty and
others not, when you force only one encoding on all platforms?
The reason for doing so would be to make code more ea
Am 12.10.2011 14:24, schrieb Michael Schnell:
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 t
Am 12.10.2011 14:26, schrieb Michael Schnell:
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. B
Am 12.10.2011 14:17, schrieb Graeme Geldenhuys:
As for you statement regarding "do we need Unicode support everywhere?"
Well, with Delphi 2009's Unicode support, the Delphi language now
supports Unicode too. Thus unit names, class names, property names,
variable names etc can all contain Unicode
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: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 12/10/2011 11:47, Martin Schreiber wrote:
> idea. Have a look at Firemonkey and you know what I mean. ;-)
For those unfamiliar with Firemonkey, would you mind explaining further.
...but over all, I do agree with your statement, that FPC shouldn't
follow Delphi blindly. Delphi and VCL is Windo
Am 12.10.2011 14:16, schrieb Sven Barth:
Am 12.10.2011 14:16, schrieb Michael Schnell:
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 sa
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 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: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
Am 12.10.2011 14:07, schrieb Michael Schnell:
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. Compil
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 encoding, formerly "native"
stri
Am 12.10.2011 10:50, schrieb Michael Schnell:
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.
Accord
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
Michael Schnell schrieb:
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 "TAnsiRe
Michael Schnell schrieb:
I understand that some day (when the official release comes up) "String"
will be a new String type and thus ANSIString obsolete and just an alias.
No. "string" is an alias (generic type), all other string types are
distinct types.
So target encoding ID "0" means tha
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
Please explain what you mean by "unicode" and what by "ansi" in your
statement. Without nuancing that, your statement is pretty much meaning
less.
AFAIR Delphi changed the string type to Unicode (UTF-16) in D2009, i.
Sven Barth schrieb:
Am 11.10.2011 23:09, schrieb Hans-Peter Diettrich:
In short, see it as if text now has a mandatory encoding attached. If
the
runtime doesn't know the type, then it is not text, but binary, and you
should treat it as such.
Can you give an example, how the runtime can not
Paul Ishenin schrieb:
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
default system codepage. It will get the real encoding number
Michael Schnell schrieb:
When I have a variable of type AnsiString, and assign an string to it,
then its encoding is reported as 1252 (my system codepage). On Paul's
machine it will have a different encoding, I assume?
Via personal consulting ( :) ) I learned that the multiple new Pascal -
s
On Wednesday 12 October 2011 11.13:45 Sven Barth wrote:
> Am 12.10.2011 10:59, schrieb Martin Schreiber:
> > On Wednesday 12 October 2011 09.50:33 Marco van de Voort wrote:
> >> Undecided. But I'm very strongly against utf16 default on unix. I don't
> >> do much GUI on unix, and it would be insane
Am 12.10.2011 10:59, schrieb Martin Schreiber:
On Wednesday 12 October 2011 09.50:33 Marco van de Voort wrote:
Undecided. But I'm very strongly against utf16 default on unix. I don't do
much GUI on unix, and it would be insane to have a string type that is
totally different from all other strin
On Wednesday 12 October 2011 09.50:33 Marco van de Voort wrote:
>
> Undecided. But I'm very strongly against utf16 default on unix. I don't do
> much GUI on unix, and it would be insane to have a string type that is
> totally different from all other string types that I touch.
Do I understand it
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
Am 12.10.2011 10:24, schrieb Michael Schnell:
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
On 12 Oct 2011, at 10:13, Jonas Maebe wrote:
That would indeed require some ifdefs to keep the code compilable
also by Delphi. No solution will be completely free.
Well, an alternative could be to add a global directive such as
{$modeswitch duplicate_all_string_based_code}
whereby anything
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
default system codepage. It will get th
On 12 Oct 2011, at 09:56, Marco van de Voort wrote:
If it was just one class it would work. But essentially it is all
OOP. (e.g.
tcomponent and tcontrol has string properties, and thus the whole of
lazarus),
Lazarus doesn't have to change anything. They are free to follow the
path you pro
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
default system codepage. It will get the real encoding number after the
first assig
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/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
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
Am 11.10.2011 23:09, schrieb Hans-Peter Diettrich:
Marco van de Voort schrieb:
Note that many places that are runtime typed (like
tstringlist.loadfromfile)
get a encoding parameter, so that the loading code can convert the
encoding
of the file (in encoding parameter) to whatever stringtype tstr
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
In our previous episode, Jonas Maebe said:
> > I know that Florian and you wanted to see the default string as something
> > of a
> > dialect mode, but I never saw a way to do that practically.
>
> How about this: a new language feature is added to the compiler that
> enables defining a type alia
In our previous episode, Hans-Peter Diettrich said:
> > Please explain what you mean by "unicode" and what by "ansi" in your
> > statement. Without nuancing that, your statement is pretty much meaning
> > less.
>
> AFAIR Delphi changed the string type to Unicode (UTF-16) in D2009, i.e.
> D2007 wa
12.10.2011 4:11, Hans-Peter Diettrich wrote:
When I have a variable of type AnsiString, and assign an string to it,
then its encoding is reported as 1252 (my system codepage). On Paul's
machine it will have a different encoding, I assume?
Yes, 1251 here.
Best regards,
Paul Ishenin.
___
Sven Barth schrieb:
Am 11.10.2011 11:35, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
Nevertheless Jonas' statement is correct, because (currently) String =
AnsiString and thus they are the same (and both can currently use code
pages).
Really? This were absolutely incompatible with Delp
Marco van de Voort schrieb:
Note that many places that are runtime typed (like tstringlist.loadfromfile)
get a encoding parameter, so that the loading code can convert the encoding
of the file (in encoding parameter) to whatever stringtype tstringlist uses
(typically utf8 or utf16 or "default")
Marco van de Voort schrieb:
In our previous episode, Hans-Peter Diettrich said:
components under Lazarus/LCL ecosystem that would need such change. Also
porting Delphi VCL components would be a lot harder.
IMO Lazarus (and FPC) should follow the Delphi way, with strictly
separate Unicode and pr
Michael Schnell schrieb:
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 well
Michael Schnell schrieb:
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 require
1 - 100 of 145 matches
Mail list logo
