8. Re: [gsoc] unicode tools and an unicode string type (Mathias Gaunard)

It's really aimed at being simple and non-intrusive. Components are fairly separate and code is thus incremental, and the unicode string just composes the work.

I personally believe basic_string, char_traits, and codecvt facets and the standard locale system are not really suitable to deal with unicode, which may have been the reason why previous proposals ended up they way

they did. I think some people said the same in the various unicode discussions, too. Efficient algorithms are provided by the Unicode consortium, so it's mostly just the design or glue code that needs work. The glue depending on what integration with other components is being done. Here, it's mostly just range concepts.

Mathias, Unfortunately the simple algorithms supplied by the Unicode consortium all end up requiring a character traits tables ! There are large tables that need to be transformed into compact sets of traits and this was done by myself and Rogier. These traits are then used to drive simple [ish] rules. So whatever you do - you need to start with the character traits tables [which are large]. Yours, Graham Barnett