>> Unicode sorting is indeed an interesting thing. But to me this >> seems rather a high level app logic problem than a disadvantage >> of Unicode. After all Unicode just makes it possible to store >> different languages next to each other, and in this case sorting >> opens a whole new problem, but even with Unicode encoded strings, >> one can opt to use a certain, language specific collation and >> put other chars f.e. to the end of list. On the database level >> this may be helped by per table (or per index) collation selection. > > In the above you are saying that you do not need native unicode support > because all what you need is some method to store characters for many > different languages. For this we for sure do not need unicode in core > code. Just simply use everywhere UTF8 and add new GT driver which will > operate on UTF8. HVM does not have to know anything about it. Such method > is already used by some GUI libraries for [x]Harbour.
I didn't say I don't need it. I said if someone needs strict national collation in some places (like the one you mentioned in your example) it can be solved even when using Unicode. What you suggest would seem to be nice solution, but one problem is that we're missing such UTF8 support in various places of Harbour. With you recent changes though, it seems to be possible to reach this state, f.e. by using new string conversion functions in places like GTWIN/GTWVT, maybe GTXWC, I don't know whether is supports UTF8, but I'd guess not, same goes for GTTRM when terminal isn't operating in UTF8 mode. So, if I understand correctly, we must use new string conversion functions all over Harbour first. There are some other problems. If I go to use UTF8 for my app strings as you suggest, I'd have to change all string handling functions to HB_UTF8*() flavors, which means support is not transparent (or "native"). >> All in all if native Unicode is good for Java and C#, I believe >> it must be good for Harbour, too. Of course we may need to solve >> some extra Clipper/.dbf-specific problems along the way. > > I do not find Unicode in Java and C# as good solution. > In general string management in these languages is one of the most > important reasons for me to not use them. Now string management in > Harbour is hundreds or even thousands times faster then in above > languages when a lot of strings have to be allocated, i.e. when > report is created and I would like to keep this performance. I'm happy Harbour is better, but is there a relation between dismal C#/Java string handling performance and their support of Unicode? Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
