[boost] Re: [Unicode strings] We're off

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-16 06:36:27

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