David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
And then you go ahead to use an unqualified mbstate_t. This just doesn't work for CW. And I don't see how this would work for any library runtime that puts mbstate_t only in the std namespace. Could you explain what your intent is for this?
The situation with mbstate_t is problematic. Some compilers define it in the global namespace while others define it in std::mbstate_t. The intent is to permit the code to use mbstate_t without qualification for those compilers that don't define it as std::mbstate_t. This sort of grew one compiler at time without too much thought. The typedef ::mbstate_t mbstate_t makes me wonder what I was thinking. Following the logic here for CW this would add
#elif defined(CW) using std::mbstate_t;
so that the rest of the code could use unqualified mbstate_t .
Seems wrong; standard is that it's only in std:: if you're not including any of the <xxx.h> headers. You ought to look for it there by default and only pluck it from the global namespace on implementations that you know to be nonconforming in this regard. Same with size_t.
Not only that... The code that's doing this is boost-root/boost/utf8_codecvt_facet.hpp which happens to be somewhat of a duplicate for the file boost-root/boost/program_options/utf8_codecvt_facet.hpp. But with the added disturbance of defining the class in the global namespace instead of a namespace within the boost group. Perhaps the intent was to place the entire thing inside some namespace and hence the mbstate_t would not collide? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq