<div dir="ltr">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><div class="gmail_extra">
<div class="gmail_quote"><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>2.14.2/2 </div>
</div></div></div>