2012/8/23 Hans-Peter Diettrich drdiettri...@aol.com:
Daniël Mantione schrieb:
Op Wed, 22 Aug 2012, schreef Felipe Monteiro de Carvalho:
On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber mse00...@gmail.com
wrote:
I am not talking about Unicode. I am talking about day by day
programming of
Op Thu, 23 Aug 2012, schreef Hans-Peter Diettrich:
Daniël Mantione schrieb:
Op Wed, 22 Aug 2012, schreef Felipe Monteiro de Carvalho:
On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber mse00...@gmail.com
wrote:
I am not talking about Unicode. I am talking about day by day programming
of
an
In our previous episode, Ivanko B said:
Do you mean replacing a character in an UCS-2/UCS-4 string can be
implemented more efficiently than in an UTF-8/UTF-16 string?
Sure, just scan the string char by char as array elements and replace
as matches encounter. Like working with integer
On Wed, 22 Aug 2012 09:34:33 +0500
Ivanko B ivankob4m...@gmail.com wrote:
Do you mean replacing a character in an UCS-2/UCS-4 string can be
implemented more efficiently than in an UTF-8/UTF-16 string?
Sure, just scan the string char by char as array elements and replace
as matches
On Wednesday 22 August 2012 02:01:09 Hans-Peter Diettrich wrote:
You still miss the point. Why deal with single characters, by index,
when working with substrings also covers the single-character use?
Why not if it is faster, simpler and more intuitive for beginners?
Martin
How many functions have you written that replaces
characters in an UTF-8/UTF-16 string with different size characters?
=
Me adore UTF-8 - a great way of storing unicode text, using non-latin
passwords,.. ! But if we have the RTL string type UTF-8 then we should
also have whole RTL
Ivanko B schrieb:
Do you mean replacing a character in an UCS-2/UCS-4 string can be
implemented more efficiently than in an UTF-8/UTF-16 string?
Sure, just scan the string char by char as array elements and replace
as matches encounter. Like working with integer arrays.
This applies only to
Ivanko B schrieb:
Why deal with single characters, by index, when working with
substrings also covers the single-character use?
Possibly because it tens times as slower for multiple chars processed.
Not really. Replacing the same amount of bytes can *always* be done
Martin Schreiber schrieb:
On Wednesday 22 August 2012 02:01:09 Hans-Peter Diettrich wrote:
You still miss the point. Why deal with single characters, by index,
when working with substrings also covers the single-character use?
Why not if it is faster, simpler and more intuitive for beginners?
Ignoring ligatures or other foreign languages' constructs and habits
will bite you, sonner or later.
==
To handle this, constantly size growing fixed-char enconings exit.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber mse00...@gmail.com wrote:
I am not talking about Unicode. I am talking about day by day programming of
an average programmer where the live is easier with utf-16 than with utf-8.
Unicode is not done by using pos() instead of character indexes.
Daniël Mantione schrieb:
Op Wed, 22 Aug 2012, schreef Felipe Monteiro de Carvalho:
On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber mse00...@gmail.com
wrote:
I am not talking about Unicode. I am talking about day by day
programming of
an average programmer where the live is easier with
On Wednesday 22 August 2012 21:47:53 Felipe Monteiro de Carvalho wrote:
On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber mse00...@gmail.com
wrote:
I am not talking about Unicode. I am talking about day by day programming
of an average programmer where the live is easier with utf-16 than
Hi,
On 20 August 2012 23:18, Hans-Peter Diettrich drdiettri...@aol.com wrote:
The Delphi developers wanted to implement what you suggest, but dropped that
approach later again.
When Embarcadero implemented Unicode support, Delphi was a pure
Windows application. They had no need to think of
On 21 August 2012 07:10, Ivanko B ivankob4m...@gmail.com wrote:
How about supporting in the RTL all versions of UCS-2 UTF-16 (for
fast per-char access etc optimizations) and UTF-8 (for unlimited
number of alphabets) ?
All access a char by index into a string code I have seen, 99.99% of
the
Am 21.08.2012 09:55, schrieb Graeme Geldenhuys:
On 21 August 2012 07:10, Ivanko Bivankob4m...@gmail.com wrote:
How about supporting in the RTL all versions of UCS-2 UTF-16 (for
fast per-char access etc optimizations) and UTF-8 (for unlimited
number of alphabets) ?
All access a char by index
For that reason there is no
speed difference between using a UTF-16 or UTF-8 encoded string. Both
can be coded equally efficient.
==
No in common, since UTF-8 needs error handling, replacing for
unconvertable bytes etc operations which may effect initial data which
makes per-byte
Me always get excited how Graeme defends the solutions of his choice :)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tue, 21 Aug 2012 14:59:57 +0500
Ivanko B ivankob4m...@gmail.com wrote:
For that reason there is no
speed difference between using a UTF-16 or UTF-8 encoded string. Both
can be coded equally efficient.
==
No in common, since UTF-8 needs error handling, replacing for
Martin Schreiber schrieb:
All access a char by index into a string code I have seen, 99.99% of
the time work in a sequential manner. For that reason there is no
speed difference between using a UTF-16 or UTF-8 encoded string. Both
can be coded equally efficient.
Graeme, this is simply not
Graeme Geldenhuys schrieb:
On 20 August 2012 23:18, Hans-Peter Diettrich drdiettri...@aol.com wrote:
The Delphi developers wanted to implement what you suggest, but dropped that
approach later again.
When Embarcadero implemented Unicode support, Delphi was a pure
Windows application. They had
Am 21.08.2012 12:52, schrieb Hans-Peter Diettrich:
The good ole Pos() can do that, why search for more complicated
implementations?
You still try to use old coding patterns which are simply inappropriate
for dealing with Unicode strings. Why make a distinction between
searching for a single
If you replied to this mail then you lost me.
I don't understand what problem of UTF-8 for the RTL you want to point
out. Can you explain again?
==
Substringing etc manipulation only via normalizing to fixed-char type
which may be inefficient (especially because it performs for each
Martin Schreiber schrieb:
Am 21.08.2012 12:52, schrieb Hans-Peter Diettrich:
The good ole Pos() can do that, why search for more complicated
implementations?
You still try to use old coding patterns which are simply inappropriate
for dealing with Unicode strings. Why make a distinction
Graeme Geldenhuys schrieb:
{$IFDEF WINDOWS}
UnicodeString = type AnsiString(CP_UTF16);
AnsiStrings consist of bytes only, for good reasons (mostly
performance). The Delphi developers wanted to implement what you
suggest, but dropped that approach later again.
String classes have
25 matches
Mail list logo
