[utility/swap] MSVC 10 test failure, unsigned long to std::bitset conversion invalid?
There's a regression failure of Microsoft Visual C++ 10 on a unit test of the boost::swap utility:
..\libs\utility\swap\test\std_bitset.cpp(20) : error C2440: 'initializing' : cannot convert from 'unsigned long' to 'std::bitset<_Bits>' No constructor could take the source type, or constructor overload resolution was ambiguous
..\libs\utility\swap\test\std_bitset.cpp(21) : error C2440
See http://www.boost.org/development/tests/trunk/developer/output/RWVC10-boost-b... Do I understand correctly that MSVC 10 does not support implicit conversion from unsigned long to std::bitset<N>? The program "std_bitset.cpp" is at http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/std_bitset.cpp It does: #include <bitset> int test_main(int, char*[]) { typedef std::bitset<8> bitset_type; const bitset_type initial_value1 = 1ul; // Line 20. const bitset_type initial_value2 = 2ul; // Line 21. // [...] return 0; } Can anyone here reproduce the compile error? If so, would it be helpful to replace line 20 and 21 by using parentheses? As follows: const bitset_type initial_value1(1ul); const bitset_type initial_value2(2ul); Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Hi Nils ! Op den Sünnavend 06 März 2010 Klock 15:50:46 hest Du schreven:
There's a regression failure of Microsoft Visual C++ 10 on a unit test Can anyone here reproduce the compile error?
Yes, using msvc-10.0 RC (I hope :-))
If so, would it be helpful to replace line 20 and 21 by using parentheses? As follows:
const bitset_type initial_value1(1ul); const bitset_type initial_value2(2ul);
This results in: std_bitset.cpp(20) : error C2668: 'std::bitset<_Bits>::bitset' : ambiguous call to overloaded function with [ _Bits=8 ] c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\bitset(136): could be 'std::bitset<_Bits>::bitset(_ULonglong)' with [ _Bits=8 ] c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\bitset(127): or 'std::bitset<_Bits>::bitset(int)' with [ _Bits=8 ] while trying to match the argument list '(unsigned long)' Just drop a note if you need more testing. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Hi Nils ! Op den Sünnavend 06 März 2010 Klock 17:18:37 hest Du schreven:
Hi Nils !
Op den Sünnavend 06 März 2010 Klock 15:50:46 hest Du schreven:
There's a regression failure of Microsoft Visual C++ 10 on a unit test Can anyone here reproduce the compile error?
Yes, using msvc-10.0 RC (I hope :-))
If so, would it be helpful
to replace line 20 and 21 by using parentheses? As follows: const bitset_type initial_value1(1ul); const bitset_type initial_value2(2ul);
So, it seem that using (1) and (2) resolves this issue: Index: std_bitset.cpp =================================================================== --- std_bitset.cpp (revision 60227) +++ std_bitset.cpp (working copy) @@ -17,8 +17,8 @@ int test_main(int, char*[]) { typedef std::bitset<8> bitset_type; - const bitset_type initial_value1 = 1ul; - const bitset_type initial_value2 = 2ul; + const bitset_type initial_value1(1); + const bitset_type initial_value2(2); bitset_type object1 = initial_value1; bitset_type object2 = initial_value2; Tested with msvc-10.0, msvc-9.0 and gcc-4.4 (mingw) Yours, Jürgen - * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
Hi Juergen ! :-)
There's a regression failure of Microsoft Visual C++ 10 on a unit test Can anyone here reproduce the compile error?
Yes, using msvc-10.0 RC (I hope :-))
Thank you!
So, it seem that using (1) and (2) resolves this issue:
Index: std_bitset.cpp =================================================================== --- std_bitset.cpp (revision 60227) +++ std_bitset.cpp (working copy) @@ -17,8 +17,8 @@ int test_main(int, char*[]) { typedef std::bitset<8> bitset_type; - const bitset_type initial_value1 = 1ul; - const bitset_type initial_value2 = 2ul; + const bitset_type initial_value1(1); + const bitset_type initial_value2(2);
bitset_type object1 = initial_value1; bitset_type object2 = initial_value2;
Tested with msvc-10.0, msvc-9.0 and gcc-4.4 (mingw)
Thanks for testing on msvc-9.0 and gcc-4.4 as well! That's great. One more question: would copy-initialization work here as well? As follows: const bitset_type initial_value1 = 1; const bitset_type initial_value2 = 2; I like that syntax better than direct-initialization (using parentheses) in this case, because I want to be sure that initial_value1 will get the value 1, and initial_value2 will get the value 2. In case of direct-initialization, the initialized object may not always get the same value as the argument. (For example: when doing std::vector<int> vec(42); vec will not get the value 42.) And in case of std::bitset, I wanted to use a non-explicit constructor anyway. If copy-initialization from int to std::bitset works well, I think I'll commit that as workaround. So Juergen, please let me know, if you can give it another try, for msvc-10.0, msvc-9.0 and gcc-4.4. Kind regards, Niels
Hi Nils, Op den Sünnavend 06 März 2010 Klock 22:17:14 hest Du schreven:
If copy-initialization from int to std::bitset works well, I think I'll commit that as workaround. So Juergen, please let me know, if you can give it another try, for msvc-10.0, msvc-9.0 and gcc-4.4.
Of course. It works: Index: std_bitset.cpp =================================================================== --- std_bitset.cpp (revision 60246) +++ std_bitset.cpp (working copy) @@ -17,8 +17,8 @@ int test_main(int, char*[]) { typedef std::bitset<8> bitset_type; - const bitset_type initial_value1 = 1ul; - const bitset_type initial_value2 = 2ul; + const bitset_type initial_value1 = 1; + const bitset_type initial_value2 = 2; bitset_type object1 = initial_value1; bitset_type object2 = initial_value2; Test compiler msvc-10.0, msvc-9.0 and gcc-4.4. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !
On 2010-03-07 10:44, Juergen Hunold wrote:
It works:
Index: std_bitset.cpp =================================================================== --- std_bitset.cpp (revision 60246) +++ std_bitset.cpp (working copy) @@ -17,8 +17,8 @@ int test_main(int, char*[]) { typedef std::bitset<8> bitset_type; - const bitset_type initial_value1 = 1ul; - const bitset_type initial_value2 = 2ul; + const bitset_type initial_value1 = 1; + const bitset_type initial_value2 = 2;
bitset_type object1 = initial_value1; bitset_type object2 = initial_value2;
Test compiler msvc-10.0, msvc-9.0 and gcc-4.4.
Thank you, Juergen. If nobody objects, I'll commit this particular workaround to the trunk, later today. I have already created a ticket, #3984, "utility/swap std_bitset regression failure on msvc-10 (RC)", https://svn.boost.org/trac/boost/ticket/3984 Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
I opened a bug on connect about that after seeing the same error on one of my own projects: https://connect.microsoft.com/VisualStudio/feedback/details/532897/problems-... The problem is that bitset in the VC10 RC has one constructor that takes an int and one that takes an unsigned long long, and if you try to call it with an unsigned long it can't work out which one to call. I thought that looked like a bug in the RC, but MS haven't commented on it yet. -- View this message in context: http://old.nabble.com/-utility-swap--MSVC-10-test-failure%2C-unsigned-long-t... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 2010-03-06 18:56, Richard Webb wrote:
I opened a bug on connect about that after seeing the same error on one of my own projects: https://connect.microsoft.com/VisualStudio/feedback/details/532897/problems-...
Cool! Thanks, Richard.
The problem is that bitset in the VC10 RC has one constructor that takes an int and one that takes an unsigned long long, and if you try to call it with an unsigned long it can't work out which one to call.
Interesting. I only have VC10 beta 1 installed, which does not have such a bitset::bitset(int). So the bug was introduced very recently! Do I understand correctly that bitset::bitset(int) behaves exactly like the old bitset::bitset(unsigned long)? Assuming that sizeof(int) == sizeof(unsigned long), of course! Kind regards, Niels
Niels Dekker - address until 2010-10-10 wrote:
Interesting. I only have VC10 beta 1 installed, which does not have such a bitset::bitset(int). So the bug was introduced very recently!
Do I understand correctly that bitset::bitset(int) behaves exactly like the old bitset::bitset(unsigned long)? Assuming that sizeof(int) == sizeof(unsigned long), of course!
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. 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-... -- View this message in context: http://old.nabble.com/-utility-swap--MSVC-10-test-failure%2C-unsigned-long-t... Sent from the Boost - Dev mailing list archive at Nabble.com.
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
Niels Dekker - address until 2010-10-10 wrote:
typedef std::bitset<8> bitset_type; const bitset_type initial_value1 = 1; const bitset_type initial_value2 = 2;
That also seems ok on mingw-4.5, in both c++98 and c++0x modes. On a side note, GCC 4.5 (4.5.0 20100225 (experimental)) seems to suffer from the same problem as VC bug 500122 when constructing from a literal 0: bitset.cpp:7:37: error: call of overloaded 'bitset(int)' is ambiguous c:\mingw450eq\bin\../lib/gcc/i686-pc-mingw32/4.5.0/../../../../include/c++/4.5.0 /bitset:864:7: note: candidates are: std::bitset<_Nb>::bitset(const char*) [with unsigned int _Nb = 8u] c:\mingw450eq\bin\../lib/gcc/i686-pc-mingw32/4.5.0/../../../../include/c++/4.5.0 /bitset:792:7: note: std::bitset<_Nb>::bitset(long long unsigned int) [with unsigned int _Nb = 8u] c:\mingw450eq\bin\../lib/gcc/i686-pc-mingw32/4.5.0/../../../../include/c++/4.5.0 /bitset:699:5: note: std::bitset<8u>::bitset(const std::bitset<8 u>&) As you say though, there are several workarounds for the problem. -- View this message in context: http://old.nabble.com/-utility-swap--MSVC-10-test-failure%2C-unsigned-long-t... Sent from the Boost - Dev mailing list archive at Nabble.com.
Am I right in thinking that the test would pass if not for a bug in MSVC10? If so, I'd be more inclined to mark the test as an expected failure on the MSVC10 than change the test itself. Joe.
On 2010-03-07 12:39, Joseph Gauterin wrote:
Am I right in thinking that the test would pass if not for a bug in MSVC10?
Yes, indeed.
If so, I'd be more inclined to mark the test as an expected failure on the MSVC10 than change the test itself.
Actually I have considered this approach as well, but I changed my mind. Because it's not the purpose of libs/utility/swap/test/std_bitset.cpp to test the initialization of an std::bitset. Its purpose is to test whether boost::swap correctly swaps two different std::bitset objects: typedef std::bitset<8> bitset_type; const bitset_type initial_value1 = <some value>; const bitset_type initial_value2 = <some other value>; bitset_type object1 = initial_value1; bitset_type object2 = initial_value2; boost::swap(object1,object2); BOOST_CHECK_EQUAL(object1,initial_value2); BOOST_CHECK_EQUAL(object2,initial_value1); How those initial_value1 and initial_value2 are actually initialized is irrelevant to the test. However, std_bitset.cpp should test whether boost::swap does the right thing, on any platform, including Microsoft Windows + VC 10. Hope you agree. But please let me know if you still object against the workaround, which just replaces "1ul" by "1", and "2ul" by "2": const bitset_type initial_value1 = 1; const bitset_type initial_value2 = 2; Of course, you can also add your comments to the ticket: https://svn.boost.org/trac/boost/ticket/3984 Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
On 2010-03-07 12:39, Joseph Gauterin wrote:
[...] I'd be more inclined to mark the test as an expected failure on the MSVC10 than change the test itself.
[ I replied: ]
Actually I have considered this approach as well, but I changed my mind. Because it's not the purpose of libs/utility/swap/test/std_bitset.cpp to test the initialization of an std::bitset. Its purpose is to test whether boost::swap correctly swaps two different std::bitset objects: [...] How those initial_value1 and initial_value2 are actually initialized is irrelevant to the test. However, std_bitset.cpp should test whether boost::swap does the right thing, on any platform, including Microsoft Windows + VC 10.
Hope you agree. But please let me know if you still object against the workaround, which just replaces "1ul" by "1", and "2ul" by "2":
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... Hope that sounds okay to you. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Given that the bug is affecting initialization rather than swapping, I agrre with you that changing the test to workaround the bug is the correct fix. Thanks for fixing it Niels. Joe.
Niels Dekker wrote:
On 2010-03-07 12:39, Joseph Gauterin wrote:
[...] I'd be more inclined to mark the test as an expected failure on the MSVC10 than change the test itself.
[ I replied: ]
Actually I have considered this approach as well, but I changed my mind. Because it's not the purpose of libs/utility/swap/test/std_bitset.cpp to test the initialization of an std::bitset. Its purpose is to test whether boost::swap correctly swaps two different std::bitset objects: [...] How those initial_value1 and initial_value2 are actually initialized is irrelevant to the test. However, std_bitset.cpp should test whether boost::swap does the right thing, on any platform, including Microsoft Windows + VC 10.
Hope you agree. But please let me know if you still object against the workaround, which just replaces "1ul" by "1", and "2ul" by "2":
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.
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. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
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
Niels Dekker wrote:
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
I can see that being an issue if the tests are compiled with C++0x features enabled. Otherwise, MSVC 10 is wrong.
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.
I can certainly appreciate that.
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;
For C++0x, the ints will be promoted to unsigned long long. For C++98/03, they will be promoted to unsigned long. Therefore, using int is appropriate for implementations that exactly match the standards. I understand that MSVC introduced an int overload for some reason. Assuming that overload behaves as expected, then it will be an exact match and should also provide the desired result.
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");
That would be silly, but it would work. How about default constructing and then setting the bits you want? _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
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
Robert Stewart wrote:
I can see that being an issue if the tests are compiled with C++0x features enabled. Otherwise, MSVC 10 is wrong.
I'm not sure, but it looks like MSVC 10 will always have its C++0x features enabled. The <bitset> header of MSVC 10 beta 1 only offers the old C++98/03 bitset(unsigned long) constructor if the macro _HAS_CPP0X is /not/ defined. But apparently _HAS_CPP0X /is/ defined, at least on the msvc-10.0 RC configuration tested here by Juergen Hunold, and on the regression site, www.boost.org/development/tests/trunk/RWVC10.html I tried to un-define _HAS_CPP0X (compiler option "/u _HAS_CPP0X"), but it doesn't seem to work.
I understand that MSVC introduced an int overload for some reason.
Note that Christopher Jefferson has just submitted an issue to the Library Working Group, which might support MSVC's extension: http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1325 This LWG issue says:
As mentioned on the boost mailing list:
The following code, valid in C++03, is broken in C++0x due to ambiguity between the "unsigned long long" and "char*" constructors.
#include <bitset> std::bitset<10> b(0);
However, I'm not convinced that this issue is properly solved by just adding a bitset(int) constructor (as MSVC 10 RC does). We wrote:
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");
That would be silly, but it would work. How about default constructing and then setting the bits you want?
That would certainly be an option as well. Although in general I'd rather directly initialize an object to the desired value, of course. Especially because it allows me to declare the object "const". Thanks, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Niels Dekker - address until 2010-10-10 wrote:
Robert Stewart wrote:
I can see that being an issue if the tests are compiled with C++0x features enabled. Otherwise, MSVC 10 is wrong.
I'm not sure, but it looks like MSVC 10 will always have its C++0x features enabled. The <bitset> header of MSVC 10 beta 1 only offers the old C++98/03 bitset(unsigned long) constructor if the macro _HAS_CPP0X is /not/ defined. But apparently _HAS_CPP0X /is/ defined, at least on the msvc-10.0 RC configuration tested here by Juergen Hunold, and on the regression site, www.boost.org/development/tests/trunk/RWVC10.html I tried to un-define _HAS_CPP0X (compiler option "/u _HAS_CPP0X"), but it doesn't seem to work.
There is some logic in yvals.h which defines _HAS_CPP0X to 1 if it's not defined already (and by default, it is defined and set to 1). If you manually define _HAS_CPP0X=0 in the project options, then the C++0x features will be disabled. -- View this message in context: http://old.nabble.com/-utility-swap--MSVC-10-test-failure%2C-unsigned-long-t... Sent from the Boost - Dev mailing list archive at Nabble.com.
I'm not sure, but it looks like MSVC 10 will always have its C++0x features enabled.
Richard Webb wrote:
There is some logic in yvals.h which defines _HAS_CPP0X to 1 if it's not defined already (and by default, it is defined and set to 1).
If you manually define _HAS_CPP0X=0 in the project options, then the C++0x features will be disabled.
Thanks, Richard! This might be an interesting C++03 backward-compatibility option. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
Niels Dekker - address until 2010-10-10 wrote:
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
And it says that the effect should be as if constructed by bitset(string(str)). This makes it illegal to use a null pointer, like 0, as this is not allowed for std::string.
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-...
Which then isn't a bug at all, but explicitly disallowed by the standard [lib.string.cons]. Bo Persson
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
On 2010-03-07 14:51, Bo Persson wrote:
And it says that the effect should be as if constructed by bitset(string(str)). This makes it illegal to use a null pointer, like 0, as this is not allowed for std::string.
Well, the bitset(const char*) constructor was never intended to be called when doing std::bitset<5> bits(0); And in C++98/C++03, such an initialization will call the bitset(unsigned long) constructor, which is entirely legal.
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-...
Which then isn't a bug at all, but explicitly disallowed by the standard [lib.string.cons].
Microsoft added the bitset(int) constructor, in order to preserve C++98 backward compatibility, when a user has set all bits to zero by doing std::bitset<N>(0). Which is nice. (And the C++ Standard allows an implementation some freedom to add extra member function overloads, according to the section "Member functions", [member.functions].) But unfortunately, by doing so, MSVC broke another C++98 use case, initializing an std::bitset<N> by an unsigned long. Which is what boost/libs/utility/swap/test/std_bitset.cpp does. Thanks for your feedback, Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center
participants (6)
-
Bo Persson -
Joseph Gauterin -
Jürgen Hunold -
Niels Dekker - address until 2010-10-10 -
Richard Webb -
Stewart, Robert