On Mon, 1 Dec 2008 21:23:34 +0100 (CET) [EMAIL PROTECTED] (Marco van de Voort) wrote:
> In our previous episode, Mattias Gaertner said: > > > In our previous episode, Mattias Gaertner said: > > > > > > > > > > I see this as a theoretic consideration. Please give a real > > > > > world (!) code example when this causes a problem. > > > > > > > > Can you give a real world example where a different RTLString > > > > for each platform solves a problem? > > > > > > It avoids pingpong repeated conversions between OS encoding and > > > whatever encoding is default. > > > > A real world example please. > > I don't have to. If you guaranteedly have two encodings into place and > combine code out multiple sources this will happen for sure. Exactly. If RTLString is several encodings this will happen for sure. And worse: It will happen more often depending on library and platform. > Keeping as much as possible in the system encoding, will limit this > only to legacy packages that haven't been properly ported yet, and at > least a hope staying away from converison hell. This depends on the apps. You can optimize for one encoding or optimize for one per platform. I know how to optimize for widestrings, for ansistring and for UTF-8 strings, but I have no experience in optimizing for multiple encodings. Maybe someone who did that can give some advice. The real world problem is (as Florian wrote): Some platforms have no choice, because they only support 'ansi'. I welcome the RTLString type. And I don't care what encoding is used for slow RTL functions and I trust that you have more experience than me to find a good solution here. But for TStrings I think multiple fixed encodings will make more trouble than Jonas' (dynamic encoding) and Lazarus' (one encoding for all platforms) ideas. Mattias _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel