[boost] Re: [serialization] CW problems...

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-07-18 00:44:15

David Abrahams wrote:

> "Robert Ramey" <ramey_at_[hidden]> 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