On Tue, 21 Aug 2012 10:23:10 -0300 Marcos Douglas <m...@delfire.net> wrote:
>[...] > >> I guess there is no good solution for TStrings. Whatever string type is > >> chosen, some programs will suffer. > > > > Why will some suffer? Simply default UnicodeString to the correct > > encoding on each platform, and no performance issues and no > > unnecessary conversions will occur. > > Make much sense and AFAIK so far no one has said why this approach > would not work. First of all: How do you define the "native encoding"? The encoding of the file system? Ext4 does not have one, HFS+ knows only normalized UTF-8. The encoding of readln/writeln? That depends on environment options rather than OS. The Unicode functions of the system libraries? Most applications rarely use them, but rather use frameworks like fpGui, MSEGui or the LCL. Linux does not have such functions. Make a poll? Then you should not call it "native encoding". Second: Why is it bad to have a platform dependent string type? - More test work. It's not sufficient any more to test a string function on one platform, you have to test it on all platforms. That's especially hard for projects where some developers have only access to a few OS. - Harder to optimize. It's easy to write a few optimized functions for one encoding. With multiple encodings you have to write multiple versions. - Loss of simplification. Some things are easy in one encoding, some are not. Because you have to support all encodings, you have to always implement the difficult encoding too. Mattias _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
