On 2010-03-07 01:05, Richard Webb wrote:
The change from unsigned long to unsigned long long is a c++0x change (c++98 says the constructor takes an unsigned long, and c++0x changes that to unsigned long long), and i think it was changed just to allow larger values.
Okay, but of course, the bitset(unsigned long long) constructor should still support passing an unsigned long as argument. Note that C++0x also adds the bitset(const char*) constructor. As proposed by LWG issue #778, by Thorsten Ottosen: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3019.html#778
The int constructor looks like an MS special that was added in the release candidate. I was wondering if it was added to help out with this other bug: https://connect.microsoft.com/VisualStudio/feedback/details/500122/bitset-5-...
Thanks! I added comment to this Microsoft report (ID 500122), as well as to yours (ID 532897). And I voted for yours: https://connect.microsoft.com/VisualStudio/feedback/details/532897/problems-... Now back to utility/swap/test/std_bitset.cpp. Juergen Hunold has just informed us that the following works well on msvc-10.0, msvc-9.0 and gcc-4.4: typedef std::bitset<8> bitset_type; const bitset_type initial_value1 = 1; const bitset_type initial_value2 = 2; Does that look fine to you as well? What if some other std library implementation provides two overloads, bitset(unsigned long) and bitset(unsigned long long), without providing the non-standard bitset(int)? Then we'd have another ambiguity! Maybe I shouldn't worry, and just commit the workaround to utility/swap/test/std_bitset.cpp, right? Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center