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
29 matches
Mail list logo
