Problems constructing a bitset from an unsigned long in the VC RC - by Numpsy

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


14
1
Sign in
to vote
ID 532897 Comments
Status Closed Workarounds
Type Bug Repros 11
Opened 2/11/2010 8:20:04 AM
Access Restriction Public

Description

In VC9, the code:

	unsigned long ul = 42;
	std::bitset<64> bits(ul);

compiles ok. But in the VC10 RC, it fails with:

error C2668: 'std::bitset<_Bits>::bitset' : ambiguous call to overloaded function
          with
          [
              _Bits=64
          ]
          c:\program files\microsoft visual studio 10.0\vc\include\bitset(136): could be 'std::bitset<_Bits>::bitset(_ULonglong)'
          with
          [
              _Bits=64
          ]
          c:\program files\microsoft visual studio 10.0\vc\include\bitset(127): or       'std::bitset<_Bits>::bitset(int)'
          with
          [
              _Bits=64
          ]
          while trying to match the argument list '(unsigned long)'


Which seems wrong (or at least bad for backwards compatability).

I also dont see a constructor that takes an int in the C++0x draft spec i have (N3000).
Sign in to post a comment.
Posted by Microsoft on 6/22/2010 at 3:02 PM
Hi,

Thanks again for reporting this bug. We've fixed it by implementing the proposed resolution for Library Issue 1325, and the fix will be available in VC11.

As always, if you have any further questions, feel free to E-mail me at stl@microsoft.com .

Stephan T. Lavavej
Visual C++ Libraries Developer
Posted by Microsoft on 3/29/2010 at 6:00 PM
Hi,

Thanks for reporting this bug. As you've discovered, we're already aware of it and will be fixing it as soon as possible. We'll keep this bug active until then.

If you have any further questions, feel free to E-mail me at stl@microsoft.com .

Stephan T. Lavavej
Visual C++ Libraries Developer
Posted by Niels Dekker on 3/13/2010 at 4:38 AM
For your information,

This bug is related to Standard C++ Library bitset issue #1325, submitted by Christopher Jefferson. There is a preliminary version of this issue at http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1325

The current proposed resolution is to replace the bitset(const char*) constructor by:

template <class charT>
explicit bitset(
     const charT *str,
     typename basic_string<charT>::size_type pos = 0,
     typename basic_string<charT>::size_type n =
     basic_string<charT>::npos,
     charT zero = charT('0'), charT one = charT('1'));

When doing so, bitset<5> bits(0) will compile well, even after removing the MSVC 10 specific bitset(int) constructor. Therefor it will allow resolving both bug ID 500122 and bug ID 532897. This resolution has been reviewed already by Stephan T. Lavavej.
Posted by Niels Dekker on 3/7/2010 at 1:27 AM
This bug causes a regression failure (compile errors) of a unit test at boost.org, which does:

    typedef std::bitset<8> bitset_type;
    const bitset_type initial_value1 = 1ul;
    const bitset_type initial_value2 = 2ul;

This little piece of code is accepted by *all* platforms tested by Boost, except for RWVC10: Microsoft Windows + VC10 release candidate.

Please check "[boost] [utility/swap] MSVC 10 test failure, unsigned long to std::bitset conversion invalid?", including replies from Juergen Hunold and Richard Webb: http://lists.boost.org/Archives/boost/2010/03/162690.php

So I'm asking you to just remove the bitset(int) constructor, which caused the ambiguity. The bitset(int) constructor is non-standard anyway. And the problem it intended to solve isn't really serious: https://connect.microsoft.com/VisualStudio/feedback/details/500122/bitset-5-bits-0-fails-with-conflict-between-longlong-and-char (Thanks, Richard!)

PS The workaround provided here by Timothy003 (using static_cast<unsigned long long>) is likely to cause problems on other platforms.
Posted by Microsoft on 2/11/2010 at 11:16 PM
Thank you for reporting the issue.
We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution.These specialized experts will follow-up with your issue.