From: Jan Langer (jan_at_[hidden])
Date: 2002-03-04 08:19:15
On Mon, 4 Mar 2002, Yitzhak Sapir wrote:
>I had written something along those lines being discussed now. My
>implementation also received a locale parameter (which defaulted to
i didn't know, is the code available?
>Some problems I had with the MSVC 6.0 distributed STL implementation: It
>turns out that in "release" mode, this std::locale() constructor would
>make an invalid memory access once in a long while. Other calls would
i did not test it with msvc*, since i have no access to it.
>It's also probably unwise to create a locale() on entry to such a
>function, since this function will be called a lot, and creating a
>locale() and extracting the facet from it could be potentially expensive
>operations. I tried to make this locale() a global singleton, but ran
>into the problems described in the call_once post. However, using a
>locale() parameter, and a proper codecvt facet within, one could perform
>any needed conversion. (There have been some UTF codecvt facets
>submitted to boost).
>Perhaps the "right" thing to do would be for the function to receive a
>reference to the facet. Then the user can pass whichever facet is
>needed or extract one from the appropriate locale?
but i have to call get_facet always before using string_cast it would be
much less usable. the reason for this function is it to take the burden
of locales and facets from the user.
anoher thing is that i do not always know which encoding i have and
which facet i must pass to string_cast. an example: if i write a
function erase for filesystem lib and i get a type basic_string <CharT>
with unknown CharT and this is the name of the file to be erased i just
want to call string_cast and don't mind and know which encoding is used
for the input-string.
but it would be possible to supply a new string_conversion and
char_conversion class for some other method of converting strings. and
pass it to string_cast as an template argument.
-- jan langer ... jan_at_[hidden] "pi ist genau drei"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk