Robert Stewart wrote:
I agree that your test isn't about initialization, but I'd have thought the better thing would be to conditionally compile MSVC 10 initialization logic to avoid breaking any other working platform.
Thanks Robert. But I'm not /entirely/ sure if the compile errors in the the test code are a true *bug* in the MSVC 10 release candidate. You see, the test code said: typedef std::bitset<8> bitset_type; const bitset_type initial_value1 = 1ul; const bitset_type initial_value2 = 2ul; And C++0x no longer offers a bitset(unsigned long) constructor, according to the Working Draft at http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2010/n3035.pdf
So I just committed that little modification of std_bitset.cpp to the trunk: https://svn.boost.org/trac/boost/changeset/60331
My idea is just to look at the regression page for a week or so, to see if it doesn't cause any other test failures. Otherwise, we have to do something else....
Watching for regressions is certainly good, but I still think you would be wise to apply an initialization workaround for the failing platforms and leave the rest alone.
I think I understand your point of view. But personally I'd rather have all platforms compiling the same code, instead of having platform-specific #ifdef's. Of course there are situations when platform-specific #ifdef's are necessary, but I'd rather avoid them. Anyway, do you think the lines of code I committed yesterday are at least *supposed* to work on all platforms? typedef std::bitset<8> bitset_type; const bitset_type initial_value1 = 1; const bitset_type initial_value2 = 2; Otherwise, if there is really no platform-independent way to initialize a std::bitset by means of an integer type of argument, I think I'd rather go for string literals: typedef std::bitset<8> bitset_type; const bitset_type initial_value1("01"); const bitset_type initial_value2("10"); Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center