<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 13, 2013 at 1:58 PM, Edward Diener <span dir="ltr"><<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 11/13/2013 2:59 PM, Jordan Rose wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
On Nov 13, 2013, at 11:47 , Edward Diener<br>
<<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@tropicsoft.<u></u>com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:eldlistmailingz@tropicsoft.com" target="_blank">eldlistmailingz@<u></u>tropicsoft.com</a>>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11/13/2013 9:46 AM, Edward Diener wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am seeing this error when testing Boost MPL with clang using the VC++<br>
RTL:<br>
<br>
"bitwise.cpp(40,25) :  error: non-type template argument evaluates to<br>
4294967295, which cannot be narrowed to type 'long' [-Wc++11-narrowing]<br>
MPL_ASSERT_RELATION( (bitor_<_0,_ffffffff>::value), ==, 0xffffffff );"<br>
<br>
The typedefs are:<br>
<br>
typedef integral_c<unsigned int, 0> _0;<br>
typedef integral_c<unsigned int, 0xffffffff> _ffffffff;<br>
<br>
The bitor_ in the Boost MPL is evaluating constants at compile time,<br>
doing a bitwise or ('|').<br>
<br>
Why does clang think that 0xffffffff is a 'long' when used in the<br>
comparison ? According to the C++ standard the type of 0xffffffff is the<br>
first of int, unsigned int, long, unsigned long, long long, unsigned<br>
long long in which its value can fit ( section 2.14.2 ). Is this a clang<br>
bug ?<br>
</blockquote>
<br>
Sorry, the problem is not as I had assumed above. It is actually<br>
because the MPL_ASSERT_RELATION macro devolves down to a template<br>
class where the values are of type 'long'. Is there something in C++11<br>
which says that implicit conversion of a value from an 'unsigned int'<br>
to a 'long' is illegal ? That is what clang is telling me but I can<br>
find no such restriction in the C++11 standard regarding this.<br>
</blockquote>
<br>
I think it’s more likely that on Windows ‘long’ is the same size as<br>
‘int’, and so you have an overflow error. You need to fix the<br>
template…which I guess means submitting a patch to Boost.<br>
</div></div></blockquote>
<br>
I tried a patch of the test code where I set:<br>
<br>
typedef integral_c<int, 0xffffffff> _ffffffff;<br>
<br>
but clang still complains that:<br>
<br>
bitwise.cpp(23,24) :  error: non-type template argument evaluates to 4294967295, which cannot be narrowed to type 'int' [-Wc++11-narrowing]<br>
typedef integral_c<int, 0xffffffff> _ffffffff;<br>
<br>
This I do not understand. Why does 0xffffffff evaluate to 4294967295 rather than -1 ? Where in the C++ standard does it say that hex literals are unsigned values by default ?</blockquote><div><br></div><div>Nothing to do with hex literals, just literals in general. If they don't fit in the range of an int, the literal is of unsigned int type so it can fit the value.</div>
</div></div></div>