Guillaume Munch wrote:
> 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".
Yes.
> 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 am confident that it is not required. Otherwise we would currently need a
replacement implementation without your patch when using boost::uint32_t on
mingw and cygwin. Besides, you implemented it already in char32_t_facets.h.
>> 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 ?
No. The bug is about gcc5 (I am using gcc 4.9.2), and on windows (it fails
for me on linux). Also, std::codecvt<...>::id is not among the missing
symbols.
Finally I found some time to do more tests:
- Cross compiling with mingw gcc 4.9.3 works.
- Compiling with clang (linking against the same libstdc++ as gcc 4.9.2)
works as well.
- Compiling with gcc 5.1 works also.
Quick tests with running the two latter versions did not show any problem,
so it really looks like gcc 4.9.2 is buggy here.
Georg
