std::make_shared fails to compile when constructing with parameters from Bitfields - c++

Question

Consider the following Smallest Recreate-able Standard Compliant Code
#include <vector>
#include <memory>
struct Foo
{
int m_field1;
Foo(int field1):m_field1(field1){};
};
typedef unsigned long DWORD;
typedef unsigned short WORD;
struct BitField {
struct {
DWORD Field1:31;
DWORD Field2:1;
} DUMMY;
};
int main()
{
std::vector<std::shared_ptr<Foo>> bar;
BitField *p = new BitField();
//This Line compiles
auto sp1 = std::shared_ptr<Foo>(new Foo((DWORD)p->DUMMY.Field1));
//But std::make_shared fails to compile
auto sp2 = std::make_shared<Foo>((DWORD)p->DUMMY.Field1);
return 0;
}
This code fails to compile in VC11 Update 2 with the following error message
1>Source.cpp(23): error C2664: 'std::shared_ptr<_Ty> std::make_shared<Foo,DWORD&>(_V0_t)' : cannot convert parameter 1 from 'DWORD' to 'unsigned long &'
1> with
1> [
1> _Ty=Foo,
1> _V0_t=DWORD &
1> ]
I cross checked on IDEONE, and it compiled successfully. Am I missing something obvious?
A connect Bug was opened https://connect.microsoft.com/VisualStudio/feedback/details/804888/with-language-extension-enabled-vc11-an-explicit-cast-is-not-creating-an-rvalue-from-bit-fields

Answer 1

This is an odd one. The following snippet compiles under the /Za (disable language extensions) compiler flag, but not without:
struct {
unsigned field:1;
} dummy = {0};
template<class T>
void foo(T&&){}
int main(){
foo((unsigned)dummy.field);
}
Error without /Za:
error C2664: 'foo' : cannot convert parameter 1 from 'unsigned int' to 'unsigned int &'
This is obviously a bug, since the cast to unsigned should simply create an rvalue, which should not be deduced as an lvalue-reference and which should not be treated as a bit-field. I have a feeling the extension for "rvalues bind to lvalue-references" plays a role here.
Please file a bug report on Microsoft Connect.

Answer 2

Here's more of a comment than an answer. It may shed some light on what's happening.
Example by Xeo
struct {
unsigned field:1;
unsigned nonfield;
} dummy = {0};
template<class T>
void foo(T&&){}
Step one: Type deduction.
[class.bit]/1 specifies "The bit-field attribute is not part of the type of the class member." Consequently, type deduction for foo(dummy.field) deduces the template parameter to be unsigned&.
Step two: overload resolution.
Although not strictly necessary here, the Standard has a nice example concerning this in [over.ics.ref]/4
[Example: a function with an “lvalue reference to int” parameter can be a viable candidate even if the corresponding argument is an int bit-field. The formation of implicit conversion sequences treats the int bit-field as an int lvalue and finds an exact match with the parameter. If the function is selected by overload resolution, the call will nonetheless be ill-formed because of the prohibition on binding a non-const lvalue reference to a bit-field (8.5.3). —end example ]
So this function is well-formed and will be selected, but the call will be ill-formed nevertheless.
Step three: Workarounds.
The OP's conversion should resolve the problem, foo( (unsigned)dummy.field ), as it yields an rvalue which leads to T being deduced as unsigned and the parameter unsigned&& is initialized from a temporary. But it seems that MSVC ignores the lvalue-to-rvalue conversion if source and destination have the same type. Writing foo( (unsigned)dummy.nonfield ) deduced T as T& as well (even with a static_cast).
The lvalue-to-rvalue conversion required to deduce T to unsigned rather than unsigned& can be enforced by using a unary +: foo( +dummy.field )

Answer 3

The compiler's error message is correct insofar as it really can't create a DWORD& from the value you pass in. The bitfield isn't the right size to be a real reference to DWORD. Whether the compiler is correct to reject your program, I can't say.
It's easy to work around, though. Simply specify the second template parameter when you call make_shared:
auto sp2 = std::make_shared<Foo, int>(p->DUMMY.Field1);
I used int because that's the constructor's argument type. You could say DWORD instead; any non-reference numeric type would probably be sufficient. You can then also forego the type-casting to DWORD. It doesn't do anything more.

Answer 4

Bit fields can't have references but are sometimes treated sorta like lvalues because they can be assigned to. Bit fields are messy IMO and you should avoid them.
but if you need to convert a bitfield to behaving exactly like an rvalue of the same type you can use a function like below.
template<class T>
T frombits(const T& x) {
return x;
}
//...
std::make_shared<Foo>(frombits(p->DUMMY.Field1));
I'm rather against specifying the template type. When you can, and always when it is intended, let the compiler deduce the type. Template argument deduction can get messy in C++11 but it has been engineered to work very well and work as it should in almost every case. Don't help the compiler and don't think you know better than it; eventually you will loose.