Boost logo

Boost :

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. -
-- rrivera/ - grafik/ - 102708583/icq

Boost list run by bdawes at, gregod at, cpdaniel at, john at