In our previous episode, Michael Schnell said: > Right, But exactly this seems to ask for dynamically encoded strings > allowing to do the user code as agnostic of the system encoding as > possible while automatic conversions are made whenever necessary, but > avoided whenever possible.
Both string types will probably be fully supported on unicode supporting platforms. The point is what the RTL uses. It makes sense to take the encoding closest to the system, to at least allow minimal conversion scenarios. > (Which as we all know can't be provided in an absolutely perfect way: in > some cases the "agnostic" user code will not work as expected and in some > other cases performance might be reduced due to multiple automatic > conversions). Yes. Note that what I say goes for the RTL, since obviously, in the core library, speed and reducing dependancies is the most important. I don't mind if some XML lib or so is is always either UTF-16 or UTF-8 (depending on pedigree). _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel