Le 30/08/2016 à 21:12, Georg Baum a écrit :
Guillaume Munch wrote:* Why ascii_num_get_facet::do_get uses from_local8bit at some point.The encoding does not matter here: Our own numpunct_facet does not override truename() and falsename(), so std::numpunct::truename() and std::numpunct::falsename() are used. I don't know why Enrico chose from_local8bit and not from_ascii() here.* Is the numpunct<lyx::char_type> facet correctly set with the way it occurs in the code?I think so. Otherwise we would have the classical separator problem, e.g. outputting 2.3 as "2,3" when using a german locale. Do you see any specific problem?
The custom facets circumvent using std::numpunct<char32_t>, e.g.
ascii_num_get_facet converts from std::numpunct<char> (which by the way
is always the C locale so one could just use from_ascii("true"), etc.).
This is the only place where there is a numpunct so I imagine that this
is the one your are referring to with "our own numpunct".
Still, we cannot assume that std::numpunct<char32_t> is available. So
either someone is confident that nothing else requires it, or it should
be implemented like the other three facets.
I do not trust versa_string, e.g. bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557
You are right, it is more risky than I thought to use versa_string. Thanks also for the explanations about iconv.
There is an additional conversion from char * to std::string. I was once told that this is less efficient (here on the LyX mailing list, but I forgot who wrote that), but I never tested that myself.Surely, but the combined amount of time and energy spent in this conversion, over all user's computers present and future, is surely less than the time and energy spent writing this reply...Well, having these changes combined with the string type changes in one patch causes all interested persons to spend more time. If you do not want comments on the empty_string changes then please do such changes in a separate patch next time (the string type changes can be done independently of removing empty_string() and empty_docstring().
Don't get me wrong, I was not implying that the discussion is a loss of time. That would not be a clever way to try to make the point that the difference is negligible ;)
Unfortunately I cannot try the patch, since I get undefined refernces to the std::codecvt functions that we previously defined for gcc on windows:
Unlike std::codecvt<boost::uint32_t>, std::codecvt<char32_t> is part of the spec so it's quite a different situation... Does it match with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66030#c7 ?
