On Sun, Sep 18, 2011 at 12:01 PM, Sven Barth
<pascaldra...@googlemail.com> wrote:
> On 18.09.2011 17:48, DaWorm wrote:

But isn't it O(n^2) only when actually using unicode strings?
Wouldn't you also be able to do something like String.Encoding := Ansi
and then all String[i] accesses would then be o(n) + x (where x is the
overhead of run time checking that it is safe to just use a memory
offset, presumably fairly short)? Of course it would be up to the user
to choose to reencode some string he got from the RTL or FCL that way
and understand the consequences.

What assumptions are the typical String[i] user going to make about
what is returned?  There will be the types that are seeing if the
fifth character is a 'C' or something like that, and for those there
probably isn't too much that is going to go wrong, they might have to
switch to "C" instead, or the compiler can make the 'C' literal a
"unicode char which is really a string" conversion at compile time.
There may be the ones that want to turn a 'C' into a 'c' by flipping
the 6th bit, and that will indeed break, and in a Unicode world,
perhaps that should break, forcing using LowerCase as needed.  And
there are those (such as myself) who often use strings as buffers for
things like serial comms.  That code will totally break if I were to
try to use a unicode string buffer, but a simple addition of
String.Encoding := ANSI or RawByteString or ShortString in the first
line would fix that, or I could bite the bullet and recode that quick
and dirty code the right way.  My point is that trying to keep the bad
habits of a single byte string world in a unicode world is
counterproductive.  They aren't the same, and all attempts to make
them the same just cause more problems than they solve.

As for the RTL and FCL, presumably they wouldn't be doing any of this
Sting[i] stuff in the first place, would they? So they aren't going to
suffer that speed penalty.  Just because one type of code is slow,
doesn't mean everything is slow.

Jeff.
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to