On 06/27/2013 05:22 PM, Sven Barth wrote:
But you do remember that I sent you a list of string types a few days ago?
I just wanted to avoid to state something that might be wrong :-[
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.o
Am 27.06.2013 13:37 schrieb "Michael Schnell" :
> As I don't have a new Delphi I in turn don't know what exactly
"UnicodeString" means.
But you do remember that I sent you a list of string types a few days ago?
Regards,
Sven
___
fpc-devel maillist - f
On 27 Jun 2013, at 03:54, luiz americo pereira camara wrote:
2013/6/21 Sergei Gorelkin :
I've profiled the code and found no conversions taking place. All the
slowdown appears to be caused by other reasons, hard to tell the
topmost
contributor. What catches the eye is the large amount of c
On 06/27/2013 02:52 PM, Marco van de Voort wrote:
These are all discussion that have raged for years, and an implementation
was made. Basta.
As I can't do any patch for the compiler myself, I can't comment on that.
-Michael
___
fpc-devel maillist -
In our previous episode, Michael Schnell said:
> Yep. But fpc is not windows-centric,
These are all discussion that have raged for years, and an implementation
was made. Basta.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freep
On 06/27/2013 12:54 PM, Hans-Peter Diettrich wrote:
Now you also should understand that a string variable points directly
to the string content, it's usable as PChar(str) without any
conversion. The other information about the string resides *before*
that address.
I did do the testing program
Michael Schnell schrieb:
2) Nothing is copied on an assignment to a string variable, except the
reference to the memory object.
Sorry, I erroneously thought about the variable itself being ref
counted, while in fact the variable is a pointer to the (hidden) String
management record,
Fine
On 06/27/2013 01:48 PM, Marco van de Voort wrote:
when storing a - say UTF-8 - String in a
stringlist and retrieving it later to a String variable with encoding
type UTF-8 a dual conversion is done.
Yes.
To me this seems absolutely silly.
Correct. Using UTF8 on Windows is silly, as it is
In our previous episode, Michael Schnell said:
> As I don't have a new Delphi I in turn don't know what exactly
> "UnicodeString" means.
utf16 as has been said hundreds of times, and can be seen in thousands of
locations on the web. If you don't get these essential features, then all
this discuss
On 06/27/2013 01:24 PM, Sven Barth wrote:
Delphi uses "String" as type for the "TStringList" and thus with
Delphi 2009 and newer this is "UnicodeString".
I did assume this.
As I don't have a new Delphi I in turn don't know what exactly
"UnicodeString" means.
From what I read I assume this
On 06/26/2013 06:19 PM, Hans-Peter Diettrich wrote:
A string variable has no encoding type stored. Only non-empty strings
have an encoding.
Sorry for bad wording. Not the String variable itself (as same is just a
pointer to the String Record) but the string Record it points to has the
field
Am 27.06.2013 13:12, schrieb Michael Schnell:
A prominent example is TStringList. I have no idea how it is
implemented in DXE, but using "decent" RawByteStrings it can be
implemented in a way that can be used with all strings without a
severe performance hit.
Delphi uses "String" as type for t
On 06/26/2013 10:28 PM, Hans-Peter Diettrich wrote:
Please note that I invited Michael Schnell to provide his version of
such RTL routines, compatible with *his* ideas about "better" string
handling.
I would be happy to do this, but unfortunately the modified behavior
would need to be imple
On 06/26/2013 08:01 PM, Sven Barth wrote:
The RTL already uses RawByteString for the concatenation helpers.
Does this code do an assignment of RawByteString to normal String with
not already matching Types (and thus create erroneous Strings) ?
I would not suppose so.
Otherwise it would be c
On 06/27/2013 12:26 PM, Marco van de Voort wrote:
That already has been decided, everything Delphi compatible.
I was just speaking hypothetic case.
The starting point of the discussion was the possibility to improve the
compiler/library and potentially introduce mode settings that introduce
On 06/26/2013 06:29 PM, Hans-Peter Diettrich wrote:
Then you have two choices:
1) convert the string as required
2) copy the content unconverted, but update the encoding
What do you mean by "you have two choices" ?
In fact the compiler designer has the choice to implement some behavior:
1) c
In our previous episode, Michael Schnell said:
> > "Should" is a complex thing here, since there is no implementation to
> > test with (and see if it has other consequences). I assume a
> > conversion should be inserted, so at least for non rawbytestrings the
> > runtime encoding always matches
On 06/26/2013 05:09 PM, Marco van de Voort wrote:
"Should" is a complex thing here, since there is no implementation to
test with (and see if it has other consequences). I assume a
conversion should be inserted, so at least for non rawbytestrings the
runtime encoding always matches the compilet
On 06/27/2013 09:51 AM, Michael Van Canneyt wrote:
There is no content pointer. The string array is appended to the "record"
I see. Thus the "pointer" is relative and implicate :-P . Silly me.
-Michael
___
fpc-devel maillist - fpc-devel@lists
On Thu, 27 Jun 2013, Michael Schnell wrote:
2) Nothing is copied on an assignment to a string variable, except the
reference to the memory object.
Sorry, I erroneously thought about the variable itself being ref counted,
while in fact the variable is a pointer to the (hidden) String mana
2) Nothing is copied on an assignment to a string variable, except the
reference to the memory object.
Sorry, I erroneously thought about the variable itself being ref
counted, while in fact the variable is a pointer to the (hidden) String
management record, which is the ref counted entity
2013/6/21 Sergei Gorelkin :
> I've profiled the code and found no conversions taking place. All the
> slowdown appears to be caused by other reasons, hard to tell the topmost
> contributor. What catches the eye is the large amount of calls to
> UniqueString, and the fact that SetCodePage goes thro
Sven Barth schrieb:
> IMO a reasonable decision should take into account the use of the
RawByteString type in RTL code, e.g. for concatenation.
The RTL already uses RawByteString for the concatenation helpers.
This means that the assumptions implied by that code have to be matched
by the R
Am 26.06.2013 18:30 schrieb "Hans-Peter Diettrich" :
>
>
>
> Michael Schnell schrieb:
>
>> On 06/26/2013 03:44 PM, Marco van de Voort wrote:
>>>
>>> There never is a conversion when assigning to/from rawbytestring,
>>
>>
>> So what do you suggest should happen when assigning a RawByteString to a
no
Michael Schnell schrieb:
On 06/26/2013 02:59 PM, Sven Barth wrote:
... And using SetCodePage you can force a conversion.
The docs say:
===
procedure SetCodePage(var S: RawByteString; CodePage: Word; Convert:
Boolean
Michael Schnell schrieb:
On 06/26/2013 03:44 PM, Marco van de Voort wrote:
There never is a conversion when assigning to/from rawbytestring,
So what do you suggest should happen when assigning a RawByteString to a
normal String ? The result could be a strange thing that is encoded
other th
Michael Schnell schrieb:
On 06/26/2013 12:05 PM, Hans-Peter Diettrich wrote:
After an assignment both strings refer to the same memory, i.e.
pchar(s1)=pchar(s2). Everything else indicates an error, somwehere.
This is exactly what I wanted to show: it results in ContentPointer,
StringLength, R
Sven Barth schrieb:
Am 26.06.2013 14:02, schrieb Michael Schnell:
On 06/26/2013 01:40 PM, Sven Barth wrote:
It's the whole use of RawByteString that the encoding is kept. For
all other string types the content will be converted
That is what I did assume, but I understood dodi in a way that he
In our previous episode, Michael Schnell said:
> > There never is a conversion when assigning to/from rawbytestring,
>
> So what do you suggest should happen when assigning a RawByteString to a
> normal String ?
"Should" is a complex thing here, since there is no implementation to test
with (an
In our previous episode, Michael Schnell said:
> On 06/26/2013 03:44 PM, Marco van de Voort wrote:
> > There never is a conversion when assigning to/from rawbytestring, so
> > this is a strange line.
>
> Sven replied to my contribution that suggested an implementation that in
> fact does a conve
On 06/26/2013 03:44 PM, Marco van de Voort wrote:
There never is a conversion when assigning to/from rawbytestring,
So what do you suggest should happen when assigning a RawByteString to a
normal String ? The result could be a strange thing that is encoded
other than the type requires. To me
On 06/26/2013 03:44 PM, Marco van de Voort wrote:
There never is a conversion when assigning to/from rawbytestring, so
this is a strange line.
Sven replied to my contribution that suggested an implementation that in
fact does a conversion when doing an assignment from a RawByteString to
a nor
In our previous episode, Michael Schnell said:
>
> If the RawByteString Variable already has a dynamic encoding type other
> than $ a conversion might or might not be necessary.
There never is a conversion when assigning to/from rawbytestring, so this is
a strange line.
_
On 06/26/2013 02:59 PM, Sven Barth wrote:
... And using SetCodePage you can force a conversion.
The docs say:
===
procedure SetCodePage(var S: RawByteString; CodePage: Word; Convert:
Boolean);
Mit der Routine
On 06/26/2013 02:59 PM, Sven Barth wrote:
It's a counter argument to "it is not possible to make use of the
encoding type of a String information that had been assigned to a
RawByteString". This function returns the current code page of the
string. And using SetCodePage you can force a conver
Am 26.06.2013 14:46, schrieb Michael Schnell:
On 06/26/2013 02:08 PM, Sven Barth wrote:
Am 26.06.2013 14:02, schrieb Michael Schnell:
That is what I did assume, but I understood dodi in a way that he
suggested that it (with normal means such as assigning to another
String) is not possible to m
On 06/26/2013 02:08 PM, Sven Barth wrote:
Am 26.06.2013 14:02, schrieb Michael Schnell:
That is what I did assume, but I understood dodi in a way that he
suggested that it (with normal means such as assigning to another
String) is not possible to make use of the encoding type of a String
infor
Am 26.06.2013 14:02, schrieb Michael Schnell:
On 06/26/2013 01:40 PM, Sven Barth wrote:
It's the whole use of RawByteString that the encoding is kept. For
all other string types the content will be converted
That is what I did assume, but I understood dodi in a way that he
suggested that it (
On 06/26/2013 01:40 PM, Sven Barth wrote:
It's the whole use of RawByteString that the encoding is kept. For all
other string types the content will be converted
That is what I did assume, but I understood dodi in a way that he
suggested that it (with normal means such as assigning to another
Am 26.06.2013 13:59, schrieb Michael Schnell:
BTW.
I think the implementation would be quite easy, straight forward, fast
and compatible.
- The compiler knows the static encoding type of each string variable.
- The dynamic encoding type of a String is preset to the static
encoding type whe
BTW.
I think the implementation would be quite easy, straight forward, fast
and compatible.
- The compiler knows the static encoding type of each string variable.
- The dynamic encoding type of a String is preset to the static
encoding type when the string is allocated
- only RawByteString
Am 26.06.2013 12:38, schrieb Michael Schnell:
On 06/26/2013 12:13 PM, Sven Barth wrote:
You do know that s2 will point to the same record of s1 after the
assignment? The contents of the string record are not copied, only
the pointer of s2 will change. See this example:
You are right (my tes
On 06/26/2013 12:05 PM, Hans-Peter Diettrich wrote:
After an assignment both strings refer to the same memory, i.e.
pchar(s1)=pchar(s2). Everything else indicates an error, somwehere.
This is exactly what I wanted to show: it results in ContentPointer,
StringLength, ReferenceCount (plus - if n
On 06/26/2013 12:13 PM, Sven Barth wrote:
You do know that s2 will point to the same record of s1 after the
assignment? The contents of the string record are not copied, only the
pointer of s2 will change. See this example:
You are right (my testing program in pre-Unicode-Delphi does show
e
Michael Schnell schrieb:
On 06/25/2013 01:20 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Supposedly the length and encoding number and code-bytecount is
copied, too.
Please understand reference counted memory objects :-]
Please check this program I tested with a pre-Unicode Delp
Am 26.06.2013 09:41, schrieb Michael Schnell:
On 06/25/2013 01:20 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Supposedly the length and encoding number and code-bytecount is
copied, too.
Please understand reference counted memory objects :-]
Please check this program I tested wi
On 06/26/2013 09:41 AM, Michael Schnell wrote:
It shows ... how it is done.
Hi DoDi,
You might be inclined to enhance the test program for me and compile it
with DXE:
AFAI understand the encoding type and as I see in
http://wiki.freepascal.org/FPC_Unicode_support :
On 06/25/2013 01:19 PM, Hans-Peter Diettrich wrote:
This is not the case :-(
A variable can not force a conversion, when a RawByteString is
assigned to it :-(
I suppose you decently tested this with the newest version of Delphi XE.
I can't comment, as I dont have DXE. :-( .
But you and the
On 06/25/2013 01:25 PM, Hans-Peter Diettrich wrote:
8 or 16 bit codes ? In Delphi XE this seems to be 16 bit, in Delphi 7
and the currently released Lazarus this seems to be 8 Bits.
Please read before confusing everything.
Sorry that I maybe did not phrase my question/ request appropriately:
On 06/25/2013 01:20 PM, Hans-Peter Diettrich wrote:
Michael Schnell schrieb:
Supposedly the length and encoding number and code-bytecount is
copied, too.
Please understand reference counted memory objects :-]
Please check this program I tested with a pre-Unicode Delphi.
It shows that (of cou
On 06/25/2013 01:19 PM, Hans-Peter Diettrich wrote:
Efficient code must be based on a single encoding, with conversions
only from and to the outer world (OS, files...).
That does not force to prevent intermediately storing a string in
something that can hold any encoding type.
-Michael
__
Michael Schnell schrieb:
On 06/24/2013 08:21 PM, Sven Barth wrote:
AnsiString:
up to 2^23-1 characters, reference counted, system encoding
(determined by the code page at compilation time AFAIK)
8 or 16 bit codes ? In Delphi XE this seems to be 16 bit, in Delphi 7
and the currently relea
Michael Schnell schrieb:
On 06/25/2013 01:05 AM, Hans-Peter Diettrich wrote:
A RawByteString can obtain any encoding, so no conversions are required.
But when assigned back to an UnicodeString, the obtained encoding is
used to convert the string.
That sounds good. The name "RAW" just misled
Michael Schnell schrieb:
On 06/25/2013 01:05 AM, Hans-Peter Diettrich wrote:
In fact it looks like only the string pointers are copied between
AnsiString and RawByteString, with the refcount changed accordingly.
Supposedly the length and encoding number and code-bytecount is copied,
too.
Plea
In our previous episode, Sven Barth said:
> AnsiString:
>up to 2^23-1 characters, reference counted, system encoding
> (determined by the code page at compilation time AFAIK)
(2^31-1 obviously, since it is 32-bit variable, but many operations
use signed types)
> WideString
>- on non-Win
On 06/24/2013 08:21 PM, Sven Barth wrote:
AnsiString:
up to 2^23-1 characters, reference counted, system encoding
(determined by the code page at compilation time AFAIK)
8 or 16 bit codes ? In Delphi XE this seems to be 16 bit, in Delphi 7
and the currently released Lazarus this seems to
On 06/25/2013 01:05 AM, Hans-Peter Diettrich wrote:
In fact it looks like only the string pointers are copied between
AnsiString and RawByteString, with the refcount changed accordingly.
Supposedly the length and encoding number and code-bytecount is copied,
too.
-Michael
_
On 06/25/2013 01:05 AM, Hans-Peter Diettrich wrote:
A RawByteString can obtain any encoding, so no conversions are required.
But when assigned back to an UnicodeString, the obtained encoding is
used to convert the string.
That sounds good. The name "RAW" just misled me to think it would not
Sven Barth schrieb:
On 24.06.2013 16:44, Hans-Peter Diettrich wrote:
I hope, now I understand that the type RawByteString ( = String
($) ) means "codesize = 1 Byte, never to be auto-converted to any
differently encoded String type variable.
No. Even if I would like such an encoding, too, D
On 24.06.2013 16:44, Hans-Peter Diettrich wrote:
I hope, now I understand that the type RawByteString ( = String
($) ) means "codesize = 1 Byte, never to be auto-converted to any
differently encoded String type variable.
No. Even if I would like such an encoding, too, Delphi doesn't impleme
On 24.06.2013 11:36, Michael Schnell wrote:
On 06/21/2013 07:43 PM, Sven Barth wrote:
Just to clear up the names: UnicodeString is *not* the code page aware
string type (although they share the "metadata" record). It is a
dynamic length 2 byte string. The code page aware string type is
AnsiStr
On 24-6-2013 17:13, Michael Schnell wrote:
On 06/24/2013 04:44 PM, Hans-Peter Diettrich wrote:
Not in Delphi. For binary data TBytes has been added.
Which (AFAIK) is not reference counting can't do "+" and thus much
less versatile.
It is also highly controversial since XE4:
For example a go
On 06/24/2013 04:44 PM, Hans-Peter Diettrich wrote:
Not in Delphi. For binary data TBytes has been added.
Which (AFAIK) is not reference counting can't do "+" and thus much less
versatile.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepasc
Michael Schnell schrieb:
On 06/24/2013 12:43 PM, Hans-Peter Diettrich wrote:
I e.g. remember your strange (Delphi incompatible) opinions about
RawByteString and encodings in a startup discussion.
Yep. As I did not have DTX to try it, I only read what I could find in
the internet and supposed
On 06/24/2013 03:11 PM, Marco van de Voort wrote:
You can funnily store utf8 in type ansistring under Delphi 7 too.
Yep. But D7 does not rely on some string to be encoded in UTF8 (but in
the ANSI table the System configuration defines), while the LCL API
wants to see the strings in UTF8 code. _
In our previous episode, Michael Schnell said:
>
> I do now that that the Delphi 7 compatible String in fpc sometimes has
> been called ANSIString, while Lazarus funnily stores UTF8 in the type
> ANSIString, even in spite of the naming.
You can funnily store utf8 in type ansistring under Delphi
On 06/24/2013 12:43 PM, Hans-Peter Diettrich wrote:
I e.g. remember your strange (Delphi incompatible) opinions about
RawByteString and encodings in a startup discussion.
Yep. As I did not have DTX to try it, I only read what I could find in
the internet and supposedly got it wrong.
I hope,
On 06/24/2013 12:43 PM, Hans-Peter Diettrich wrote:
This should be clear since a long time.
Sorry, but e.g. I don't know the "official" names of the Delphi 7
compatible "String" and the Delphi XE compatible "String" in fpc/Lazarus.
I suppose in DXE the Delphi 7 compatible String is not avai
Michael Schnell schrieb:
Could you give us a list of the different - legacy and to be supported
- string types we might be seeing including their "official" names to
make the discussion less ambiguous.
This should be clear since a long time. I e.g. remember your strange
(Delphi incompatible
On 06/21/2013 07:43 PM, Sven Barth wrote:
Just to clear up the names: UnicodeString is *not* the code page aware
string type (although they share the "metadata" record). It is a
dynamic length 2 byte string. The code page aware string type is
AnsiString.
Thanks for making this clear.
C
Am 21.06.2013 16:29, schrieb Sergei Gorelkin:
> and the fact that SetCodePage goes through implicit
> try..finally block even if it does not need to convert the string.
I've fixed this one on r24942
___
fpc-devel maillist - fpc-devel@lists.freepascal.
Am 21.06.2013 10:36 schrieb "Michael Schnell" :
>
> On 06/21/2013 09:54 AM, Hans-Peter Diettrich wrote:
>>
>>
>> Again I'd assume that the memory allocation for the result is the most
expensive operation with UnicodeString operands, independent from string
lengths.
>>
>
> Do you suggest that with U
Michael Schnell schrieb:
On 06/21/2013 02:20 PM, Hans-Peter Diettrich wrote:
Please note that I was *not* talking about AnsiStrings.
Sorry I don't understand.
You snipped the context, which was UnicodeString (second case). The
AnsiString case was covered before.
I recon the OP asking abo
On 06/21/2013 04:29 PM, Sergei Gorelkin wrote:
What catches the eye is the large amount of calls to UniqueString,
It would be interesting to see whether the old (not "new Unicode
library") project does the same amount of UniqueString. I don't see why
the new library should do more of these c
On 21.06.2013 17:11, luiz americo pereira camara wrote:
2013/6/21 Michael Schnell :
On 06/20/2013 05:31 PM, luiz americo pereira camara wrote:
Maybe in that example there's going an (unneeded) conversion?
If you use the same string type all over the place it would be a severe bug
if _any_ co
On 06/21/2013 02:20 PM, Hans-Peter Diettrich wrote:
Please note that I was *not* talking about AnsiStrings.
Sorry I don't understand.
I recon the OP asking about a performance hit, meant a degradation
regarding the "new" (Delphi XE compatible") vs the "old" (Delphi 7
compatible) String lib
2013/6/21 Michael Schnell :
> On 06/20/2013 05:31 PM, luiz americo pereira camara wrote:
>>
>> Maybe in that example there's going an (unneeded) conversion?
>
> If you use the same string type all over the place it would be a severe bug
> if _any_ conversion is done.
>
> Please check.
>
The affect
Michael Schnell schrieb:
On 06/21/2013 09:54 AM, Hans-Peter Diettrich wrote:
Again I'd assume that the memory allocation for the result is the most
expensive operation with UnicodeString operands, independent from
string lengths.
Do you suggest that with UnicodeString - even when using 1
On 06/21/2013 09:54 AM, Hans-Peter Diettrich wrote:
Again I'd assume that the memory allocation for the result is the most
expensive operation with UnicodeString operands, independent from
string lengths.
Do you suggest that with UnicodeString - even when using 1 Byte encoding
types such
Michael Schnell schrieb:
On 06/20/2013 05:31 PM, luiz americo pereira camara wrote:
The point is that i would expect a smaller performance hit when
there's no conversion going on. Something between 10% slower. In the
cited case is more than 50% slow.
As the "dynamic" types of (most) String Var
On 06/20/2013 05:31 PM, luiz americo pereira camara wrote:
Maybe in that example there's going an (unneeded) conversion?
If you use the same string type all over the place it would be a severe
bug if _any_ conversion is done.
Please check.
-Michael
On 06/20/2013 05:31 PM, luiz americo pereira camara wrote:
The point is that i would expect a smaller performance hit when
there's no conversion going on. Something between 10% slower. In the
cited case is more than 50% slow.
As the "dynamic" types of (most) String Variables are already defined
20.06.2013 19:31, luiz americo pereira camara пишет:
Maybe in that example there's going an (unneeded) conversion?
This is possible. One needs to profile the example to tell for sure.
Regards,
Sergei
___
fpc-devel maillist - fpc-devel@lists.freepa
2013/6/20 Sergei Gorelkin :
> 20.06.2013 16:15, luiz americo pereira camara пишет:
>
>> I looked at
>> http://forum.lazarus.freepascal.org/index.php/topic,21223.0.html
>>
>> There's a significant performance drop in fpc trunk
>>
>> Is there anything wrong or this is the expected result?
>>
> Some s
20.06.2013 16:15, luiz americo pereira camara пишет:
I looked at http://forum.lazarus.freepascal.org/index.php/topic,21223.0.html
There's a significant performance drop in fpc trunk
The difference of generated code is a call to fpc_ansistr_assign and a
different implementation of fpc_AnsiStr_Co
I looked at http://forum.lazarus.freepascal.org/index.php/topic,21223.0.html
There's a significant performance drop in fpc trunk
The difference of generated code is a call to fpc_ansistr_assign and a
different implementation of fpc_AnsiStr_Concat
AFAIK there should be significant performance hit
86 matches
Mail list logo
