Hello Lazarus-List, Monday, February 14, 2011, 8:52:27 PM, you wrote:
>> 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). MvdV> Typical example is you mix two codebases which have a different opinion MvdV> about the string type. Then for every transition between those two codebases MvdV> you have a fair chance that a conversion is needed. It is throughout MvdV> possible that if you do an Tstringlist.indexof() that you do as many MvdV> conversions as elements in the stringlist (if your passed stringtype is MvdV> different from the tstringlist one). But you are in the same trouble if you use any other approach, or you use your data in the same unicode format as the other codebase or you update the codebase to use your "new" unicode format. There isn't a solution for such situation. I'm currently working with GeckoPort which uses WideString in every place and other special strings. I know that conversions must happend so when I need to scan for a string first convert my data to the "native" format and them perform the scan. I think expecting a TStringList in ansi encode to work transparently and optimal using unicodestrings is just a dream, programmers should update their codebase, but at least only for speed (reduce autoconversions) and do not need to decide constantly which encoding format is needed to call this or that function. Using a different RTL for each encoding is even worst IMHO. But this is just a simple opinion. -- Best regards, José -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus