On Mon, 14 Feb 2011 20:13:45 +0100 José Mejuto <[email protected]> wrote:
> Hello Lazarus-List, > > Monday, February 14, 2011, 7:03:31 PM, you wrote: > > JH> Do you mean that the compiler should convert the strings as needed in > JH> the background (as between different integer types and/or floats) so > JH> that you can call ListBox1.Items.Add(x) with x beeing UTF8string or > JH> UTF16string or...? I am not sure whether this is a good idea because the > JH> programmer no longer knows how many conversions take place and therefore > JH> cannot judge the performance impact anymore. On the other hand it would > JH> make the life easier for beginners. > > I'm unable to see the "great" problems with "UnicodeString". The > conversions should be the minimun needed, and they will be. Problem > would be in the RTL, but not at user level. Yes, since for example Linux allows non valid UTF-8 as file names, so any auto conversion of file names to UTF-16 is an error. > You say that the > programmer will not know how many conversions take place, that's > right, but I think they are garanteed to be the minimum except in some > corner cases like "CompareText(UTF8String,WideString)" as one of both > must be converted, but whichever one, could be a fixed situation or > platform dependent, I do not know. > > Many people are concerned about "speed" due hidden conversions, so can > anybody tell me why ? Maybe I'm blind and I can not see something that > is absolutly a problem (except some pieces of RTL). For instance searching needs a lot of compares. Comparing two strings normally fails on the very first characters. An auto conversion will always convert the whole string including allocating and releasing memory, easily slowing down the conversion by an order of magnitude. Mattias -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
