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
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
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 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
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 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
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 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/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
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 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
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
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: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
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 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
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 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 -
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
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 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
21 matches
Mail list logo
