On 11 Nov 2008, at 13:56, Michael Schnell wrote:
If this really is two codes for the same unicode character, the "friendly old school" handling function should normalize it. If someone really needs to take the differences into account (like with the case you described), he ought to do the appropriate code (handling subcodes).
It was just one example. Look at Peter Green's mail for others. The run time library (with the help of complex routines) can indeed just destroy all data of which it thinks that you do not care about when using "friendly string" handling (because it is not representable in some ISO ansi encoding that the developer is familiar with), but in that case you will probably end up with something that turns out to be useful for only a very limited number of people, and which in the real world comes crashing down horribly all the time. Yet, it will require an enormous amount of implementation work to actually support all this alleged friendliness
If people want to rely on what they are used to in non-unicode environments, then they cannot directly use unicode strings. They'll first have to assign it or typecast it to a non-unicode string and then operate on that string. At least if there's any data loss in that case, the programmer has full responsibility and knows (or should know) the risks.
Jonas _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
