From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-03-16 06:36:27
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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk