AllanW@my-dejanews.com wrote:
>
> My rule of thumb is to avoid templates where they are not needed.
> Surely this applies to a logical xor() function, where by definition
> the arguments must be convertible to bool!  I came up with:
>
>     inline bool xor(bool a,bool b) { return a!=b; }
>
> But this had problems for large inputs:
>
>     int main() {
>         const int i1=0x8000, i2=0;
>         const long b1=0x33221100, b2=0;
>         cout << (i1 && i2) << (i1 || i2) << xor(i1,i2) << endl;
>         cout << (b1 && b2) << (b1 || b2) << xor(b1,b2) << endl;
>         return 0;
>     }
> The program output:
>     010
>     010
> However, if you take out the "const" keywords, the program displays
>     011
>     011
> which I believe to be correct.  I use Microsoft Visual C++ 5.0.  By
> playing around, I found that the compiler is only using the low 8 bits
> of a const value.  Furthermore, the compiler displays a warning when
> the number is a literal:
>         Xor(0x33221100, 0);
>     warning C4305: 'argument' : truncation from 'const int' to 'bool'
> But this doesn't happen when the number is a declared const int:
>         Xor(i1, 0);
>     (no warning)
>
> Is it supposed to?  Can someone with the FDIS look up conversion types
> to bool from larger integral types?

Any nonzero number is supposed to convert to true, no matter how big.
VC++ is wrong when you take out the "const". I also don't think it
should warn about the truncation, since conversion to bool isn't really
a truncation but a meaningful conversion. However, I don't think the
standard prohibits the warning.

Your definition of xor should even work for different nonzero values.
That is, xor(12345678, 87654321) should return false, since both numbers
should convert to true.

I wonder if VC++ makes the same error if you remove the "inline". Lots
of bugs of this sort only occur when functions are inlined, since the
compiler writers feel an obligation to make inlining as smart as
possible. That is, a correct implementation might use two temporary byte
locations on the stack, convert the parameters to the appropriate 0 or 1
byte values and store them there, and then fetch them and compare them.
Given the ugliness of such code, it is tempting to try to do better, and
they probably screwed it up.

--

Ciao,
Paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
...
> which I believe to be correct.  I use Microsoft Visual C++ 5.0.  By playing
> around, I found that the compiler is only using the low 8 bits of a const
[when converting int->bool.]
...
> Is it supposed to?  Can someone with the FDIS look up conversion types
> to bool from larger integral types?
>     * What I THINK it says is nothing in particular, just lumping bool in
>       with all the other integer conversions.  That would require compilers
>       to be consistent with other integral conversions; that is, they would
>       use the lowest N bits and possibly issue a warning message.
>     * What I HOPE it says is that bool is a special case.  Zero is converted
>       to false, and anything else is converted to true.  This is consistent

I don't have the FDIS, but in CD2, section 4.12 "Boolean Conversions"
says:

1 An  rvalue  of  arithmetic, enumeration, pointer, or pointer to member
  type can be converted to an rvalue of type bool.  A zero  value,  null
  pointer value, or null member pointer value is converted to false; any
  other value is converted to true.

This looks like yet another way in which MSVC++ is out of sync with the
draft standard. What a surprise :-)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Dan Shappir's C++ riddle page
( http://www.math.tau.ac.il/~shappir/cppriddles.html#20 ), in the
solution to puzzle 20, he defines a LOGICAL (not bitwise) xor function:

    template <class T>
    inline bool Xor(T a,T b) { return !a != !b; }

My rule of thumb is to avoid templates where they are not needed.  Surely
this applies to a logical xor() function, where by definition the arguments
must be convertible to bool!  I came up with:

    inline bool xor(bool a,bool b) { return a!=b; }

But this had problems for large inputs:

    int main() {
        const int i1=0x8000, i2=0;
        const long b1=0x33221100, b2=0;
        cout << (i1 && i2) << (i1 || i2) << xor(i1,i2) << endl;
        cout << (b1 && b2) << (b1 || b2) << xor(b1,b2) << endl;
        return 0;
    }
The program output:
    010
    010
However, if you take out the "const" keywords, the program displays
    011
    011
which I believe to be correct.  I use Microsoft Visual C++ 5.0.  By playing
around, I found that the compiler is only using the low 8 bits of a const
value.  Furthermore, the compiler displays a warning when the number is a
literal:
        Xor(0x33221100, 0);
    warning C4305: 'argument' : truncation from 'const int' to 'bool'
But this doesn't happen when the number is a declared const int:
        Xor(i1, 0);
    (no warning)

Is it supposed to?  Can someone with the FDIS look up conversion types
to bool from larger integral types?
    * What I THINK it says is nothing in particular, just lumping bool in
      with all the other integer conversions.  That would require compilers
      to be consistent with other integral conversions; that is, they would
      use the lowest N bits and possibly issue a warning message.
    * What I HOPE it says is that bool is a special case.  Zero is converted
      to false, and anything else is converted to true.  This is consistent
   >
<input type=

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]