Hi Erik, Let me first say that its good to see that progress is happening on this important topic. Here are just some small comments; I didn't follow the first discussion, so maybe these things have already been answered. | Current design: | The current design is based around the concept of «encoding_traits». Is entirely improper to make unicode strings a typedef for std::basic_string<...> ? |The string class itself is created with encoding transparency in mind. |Also at the class level. This means that the encoding used in the string |is not a template parameter of the string class itself (making each |instantiation of the string it's own type), but rather a parameter of an |implementation class that is used internally to hold the string. ... |The reason for doing this is that it allows functions that take |encoded_string parameters to be blissfully unaware of what encoding they |are working on, without having to templatize (it that a word?) the |function itself. (Something I understood was a bit of a worry for some |in the last discussion.) An alternate way of doing this (something we |also tested when developing the current version), is to simply template |the string class itself on encoding, but then you loose the above |advantage of being able to have non-template functions working on |multipe encodings. and what is the benefit of having a function vs a function template? surely a function template will look the same to the client as an ordinary function; Is it often used that people must change encoding on the fly? |You do however gain speed (I would assume), since you |wouldn't have the overhead of virtual function-calls, as well as a less |complex implementation. It would be good to see some real data on how much slower it gets. If the slowdown is high, then you should consider a two-layered approach (implementing the virtual functions in terms of the non-virtual) or to remove the virtual functions altogether. -Thorsten