"bool const a( 5 )" in "Microsoft Visual Studio C++ 2010"

Discussion in 'C++' started by Stefan Ram, Sep 28, 2011.

  1. Stefan Ram

    Stefan Ram Guest

    I compiled and executed (via Ctrl-F5)

    #include <iostream>
    #include <ostream>

    int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n'; }

    in »Microsoft Visual Studio 2010 C++ Express, Version 10.0.30319.1 RTMRel«
    (a recent version) with the default settings (the Debug configuration as
    preconfigured).

    It printed:

    0

    . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
    conversion about non-zero values:

    »any other value is converted to true.«

    ?
     
    Stefan Ram, Sep 28, 2011
    #1
    1. Advertising

  2. On 28.09.2011 16:40, Stefan Ram wrote:
    > I compiled and executed (via Ctrl-F5)
    >
    > #include<iostream>
    > #include<ostream>
    >
    > int main(){ bool const a( 5 ); ::std::cout<<( a == true )<< '\n'; }
    >
    > in »Microsoft Visual Studio 2010 C++ Express, Version 10.0.30319.1 RTMRel«
    > (a recent version) with the default settings (the Debug configuration as
    > preconfigured).
    >
    > It printed:
    >
    > 0


    I have confirmed this behavior with MSVC 10.0.


    > . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
    > conversion about non-zero values:
    >
    > »any other value is converted to true.«
    >
    > ?


    It's a Visual C++ compiler bug.

    g++ does not have this bug.


    Cheers & hth.,

    - Alf
     
    Alf P. Steinbach, Sep 28, 2011
    #2
    1. Advertising

  3. Stefan Ram

    Balog Pal Guest

    "Stefan Ram" <-berlin.de>

    > I compiled and executed (via Ctrl-F5)
    >
    > #include <iostream>
    > #include <ostream>
    >
    > int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n'; }
    >
    > in »Microsoft Visual Studio 2010 C++ Express, Version 10.0.30319.1
    > RTMRel«
    > (a recent version) with the default settings (the Debug configuration as
    > preconfigured).
    >
    > It printed:
    >
    > 0
    >
    > . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
    > conversion about non-zero values:
    >
    > »any other value is converted to true.«


    Yep. Bug-ridden compiler :-(. VS2008 does the same. It even prints a
    warning about converting int to const bool, but then leaves its value at 5,
    that can be printed. If you remove 'const' and only use bool, then value is
    1 and prints 1 for comarision.
     
    Balog Pal, Sep 28, 2011
    #3
  4. Stefan Ram wrote:

    > . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
    > conversion about non-zero values:
    >
    > »any other value is converted to true.«
    >
    > ?


    Oh yes! This has bitten me numerous times. Erroneously declared a function
    parameter as bool instead of int and got very strange results. :(
     
    Paul Brettschneider, Sep 28, 2011
    #4
  5. Stefan Ram

    Edek Guest

    On 09/28/2011 08:28 PM, Paul Brettschneider wrote:
    > Stefan Ram wrote:
    >
    >> . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
    >> conversion about non-zero values:
    >>
    >> »any other value is converted to true.«
    >>
    >> ?

    >
    > Oh yes! This has bitten me numerous times. Erroneously declared a function
    > parameter as bool instead of int and got very strange results. :(


    I don't think that is the point; it is about the standard conversion
    to bool, which many programmers rely on and which is well specified
    in the standard.

    Edek
     
    Edek, Sep 28, 2011
    #5
  6. Stefan Ram

    Jorgen Grahn Guest

    On Wed, 2011-09-28, Balog Pal wrote:
    > "Stefan Ram" <-berlin.de>
    >
    >> I compiled and executed (via Ctrl-F5)
    >>
    >> #include <iostream>
    >> #include <ostream>
    >>
    >> int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n'; }
    >>
    >> in »Microsoft Visual Studio 2010 C++ Express, Version 10.0.30319.1
    >> RTMRel«
    >> (a recent version) with the default settings (the Debug configuration as
    >> preconfigured).
    >>
    >> It printed:
    >>
    >> 0
    >>
    >> . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
    >> conversion about non-zero values:
    >>
    >> »any other value is converted to true.«

    >
    > Yep. Bug-ridden compiler :-(. VS2008 does the same. It even prints a
    > warning about converting int to const bool, but then leaves its value at 5,
    > that can be printed. If you remove 'const' and only use bool, then value is
    > 1 and prints 1 for comarision.


    That surprises me -- it's a fairly visible and very dangerous bug, and
    I thought the MS compilers were really good these days. Or did I miss
    something? (I don't use them myself.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Sep 29, 2011
    #6
  7. mmm in the recently released Developer Preview of
    visual Studio 11 the bug is still present! Very
    disappointing!!

    Cheers,
    Fulvio Esposito
     
    Fulvio Esposito, Sep 29, 2011
    #7
  8. Stefan Ram

    Balog Pal Guest

    "Jorgen Grahn" <>
    >>> int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n'; }

    >>
    >> Yep. Bug-ridden compiler :-(. VS2008 does the same. It even prints a
    >> warning about converting int to const bool, but then leaves its value at
    >> 5,
    >> that can be printed. If you remove 'const' and only use bool, then value
    >> is
    >> 1 and prints 1 for comarision.

    >
    > That surprises me -- it's a fairly visible and very dangerous bug, and
    > I thought the MS compilers were really good these days.


    Me too. For the record, VS6 does not have this bug. It was picked up on the
    way up.
     
    Balog Pal, Sep 29, 2011
    #8
  9. Stefan Ram

    Krice Guest

    On 29 syys, 15:13, Jorgen Grahn <> wrote:
    > I thought the MS compilers were really good these days. Or did I miss
    > something?


    VC++ is teaching to avoid mixing numbers with bool type.
    It's a good lesson!
     
    Krice, Sep 29, 2011
    #9
  10. Stefan Ram

    Geoff Guest

    On Wed, 28 Sep 2011 17:04:54 +0200, "Alf P. Steinbach"
    <> wrote:

    >On 28.09.2011 16:40, Stefan Ram wrote:
    >> I compiled and executed (via Ctrl-F5)
    >>
    >> #include<iostream>
    >> #include<ostream>
    >>
    >> int main(){ bool const a( 5 ); ::std::cout<<( a == true )<< '\n'; }
    >>
    >> in »Microsoft Visual Studio 2010 C++ Express, Version 10.0.30319.1 RTMRel«
    >> (a recent version) with the default settings (the Debug configuration as
    >> preconfigured).
    >>
    >> It printed:
    >>
    >> 0

    >
    >I have confirmed this behavior with MSVC 10.0.
    >
    >
    >> . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
    >> conversion about non-zero values:
    >>
    >> »any other value is converted to true.«
    >>
    >> ?

    >
    >It's a Visual C++ compiler bug.
    >
    >g++ does not have this bug.
    >
    >


    But VS emits a warning:

    warning C4305: 'initializing' : truncation from 'int' to 'const bool'

    The compiler is putting the bit into a (mov byte ptr [a],1)
    but it's pushing 0 to the cout << operator.
     
    Geoff, Sep 29, 2011
    #10
  11. Stefan Ram

    Balog Pal Guest

    "Paavo Helde" <>
    > "Balog Pal" <> wrote in news:j62hha$2sej$:
    >
    >>>>> int main(){ bool const a( 5 ); ::std::cout <<( a == true )<< '\n';
    >>> That surprises me -- it's a fairly visible and very dangerous bug,
    >>> and I thought the MS compilers were really good these days.

    >>
    >> Me too. For the record, VS6 does not have this bug. It was picked up
    >> on the way up.


    It's weird. When I tried it hours ago, it gave 1 for value, 1 for compare,
    now using the same code it gives 0 for compare...


    > Does VS6 allow
    >
    > bool const a( 5 );
    > char arr[a];
    >
    > VS2010 accepts the code and makes an array containing 5 elements.
    >
    > Also interesting:
    >
    > int main() {
    > bool const a( 0xfff );
    > const int x=a;
    > char arr[x+1];
    > }
    >
    > produces:
    > 1>consoletest.cpp(8): error C2466: cannot allocate an array of constant
    > size 0


    This code in VS5:


    #include <iostream>
    #include <ostream>

    int main()
    {
    bool const a( 5 );
    ::std::cout << a <<( a == true )<< '\n';
    char c[a];
    ::std::cout << sizeof(c) << '\n';

    bool const b( 0xfff );
    const int x=b;
    char arr[x+1];
    ::std::cout << sizeof(arr) << '\n';

    return 0;
    }

    gives

    E:\m32\try\t1\t1.cpp(309) : warning C4305: 'initializing' : truncation from
    'const int' to 'const bool'
    E:\m32\try\t1\t1.cpp(314) : warning C4305: 'initializing' : truncation from
    'const int' to 'const bool'
    E:\m32\try\t1\t1.cpp(315) : warning C4309: 'initializing' : truncation of
    constant value
    E:\m32\try\t1\t1.cpp(316) : warning C4101: 'arr' : unreferenced local
    variable
    E:\m32\try\t1\t1.cpp(311) : warning C4101: 'c' : unreferenced local variable

    and prints:

    10
    5
    4096
     
    Balog Pal, Sep 29, 2011
    #11
  12. Stefan Ram

    Miles Bader Guest

    Jorgen Grahn <> writes:
    > That surprises me -- it's a fairly visible and very dangerous bug, and
    > I thought the MS compilers were really good these days. Or did I miss
    > something? (I don't use them myself.)


    MS compilers seem to optimize pretty well, etc, but _don't_ seem so
    good at being standards-conforming.

    I think one reason is that MS is reallly big on backward-
    compatibility, even when it means continuing to support horrible
    crufty old code that's completely invalid according to the standard.
    So bugs and misfeatures of past releases have a way of getting locked
    in...

    [A big chunk of my time at work is twisting "but it compiled with VS!"
    code into shape so that other compilers can compile it too...]

    -miles

    --
    In New York, most people don't have cars, so if you want to kill a person, you
    have to take the subway to their house. And sometimes on the way, the train
    is delayed and you get impatient, so you have to kill someone on the subway.
    [George Carlin]
     
    Miles Bader, Sep 30, 2011
    #12
  13. Stefan Ram

    Jorgen Grahn Guest

    On Fri, 2011-09-30, Miles Bader wrote:
    > Jorgen Grahn <> writes:
    >> That surprises me -- it's a fairly visible and very dangerous bug, and
    >> I thought the MS compilers were really good these days. Or did I miss
    >> something? (I don't use them myself.)

    >
    > MS compilers seem to optimize pretty well, etc, but _don't_ seem so
    > good at being standards-conforming.
    >
    > I think one reason is that MS is reallly big on backward-
    > compatibility, even when it means continuing to support horrible
    > crufty old code that's completely invalid according to the standard.
    > So bugs and misfeatures of past releases have a way of getting locked
    > in...
    >
    > [A big chunk of my time at work is twisting "but it compiled with VS!"
    > code into shape so that other compilers can compile it too...]


    Are you talking about recent MS compilers, with a decent set of
    standard-compliance options enabled? The venerable VS6 certainly had
    that reputation.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Sep 30, 2011
    #13
  14. Stefan Ram

    Miles Bader Guest

    Jorgen Grahn <> writes:
    > On Fri, 2011-09-30, Miles Bader wrote:
    > > MS compilers seem to optimize pretty well, etc, but _don't_ seem so
    > > good at being standards-conforming.

    ....
    > > [A big chunk of my time at work is twisting "but it compiled with VS!"
    > > code into shape so that other compilers can compile it too...]


    > Are you talking about recent MS compilers, with a decent set of
    > standard-compliance options enabled? The venerable VS6 certainly
    > had that reputation.


    I think the version most people use around here (from which stems much
    my practical experience) is VS2008.

    -Miles

    --
    Dawn, n. When men of reason go to bed.
     
    Miles Bader, Oct 1, 2011
    #14
  15. Stefan Ram

    Peter Guest

    Is this some bad joke? Are we talking about a COMMERCIAL compiler
    released a year ago? Please tell me these results are obtained for
    some weird configuration and otherwise they're correct.
    Some fundamental pieces of code are miscompiled here! If this, in
    fact,
    is VC++ 2010's typical behaviour, how did it go unnoticed and how are
    people not AFRAID to build their applications with it?
     
    Peter, Oct 3, 2011
    #15
  16. Stefan Ram

    Jorgen Grahn Guest

    On Mon, 2011-10-03, Leigh Johnston wrote:
    > On 03/10/2011 22:35, Leigh Johnston wrote:
    >> On 03/10/2011 22:28, Peter wrote:
    >>> Is this some bad joke? Are we talking about a COMMERCIAL compiler
    >>> released a year ago? Please tell me these results are obtained for
    >>> some weird configuration and otherwise they're correct.
    >>> Some fundamental pieces of code are miscompiled here! If this, in
    >>> fact,
    >>> is VC++ 2010's typical behaviour, how did it go unnoticed and how are
    >>> people not AFRAID to build their applications with it?

    >>
    >> This bug probably exists because it is a rare event indeed for a good
    >> programmer to actually assign an int to a bool so most good programmers
    >> need not worry; I am certainly not going to lose any sleep over this
    >> particular compiler bug.

    >
    > My mistake: in this case we are actually talking about initialization
    > rather then assignment but my argument still holds.


    I disagree -- this conversion to bool is a well-known feature of C++,
    and feels like something I might do, for example when interfacing with
    ancient code or C code which has its own typedefs, enums of defines
    for bool, true and false.

    Perhaps the special circumstances needed to trigger it makes it
    appear extremely rarely in real code -- I can't really tell.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Oct 4, 2011
    #16
  17. Edek wrote:

    > On 09/28/2011 08:28 PM, Paul Brettschneider wrote:
    >> Stefan Ram wrote:
    >>
    >>> . But didn't ISO/IEC 14882:2011 say in 4.12 Boolean
    >>> conversion about non-zero values:
    >>>
    >>> »any other value is converted to true.«
    >>>
    >>> ?

    >>
    >> Oh yes! This has bitten me numerous times. Erroneously declared a
    >> function parameter as bool instead of int and got very strange results.
    >> :(

    >
    > I don't think that is the point; it is about the standard conversion
    > to bool, which many programmers rely on and which is well specified
    > in the standard.


    Yes, I know what the point was. :) I was just complaining about this
    behaviour, which took me by surprise more than once, even though it is well
    documented.

    Either treat bools like a normal integer type (with a size optimized for the
    use as flag, e.g. char for x86, int for RISC) or make the conversion non-
    explicit. But I understand that the reasons for the standard compliant
    behaviour are historical and this has been discussed at length before. One
    of the terrible legacy things we have to live with.
     
    Paul Brettschneider, Oct 8, 2011
    #17
  18. Stefan Ram

    Miles Bader Guest

    Paul Brettschneider <> writes:
    > Either treat bools like a normal integer type (with a size optimized for the
    > use as flag, e.g. char for x86, int for RISC) or make the conversion non-
    > explicit. But I understand that the reasons for the standard compliant
    > behaviour are historical and this has been discussed at length before. One
    > of the terrible legacy things we have to live with.


    Wait, why is it "terrible"? This conversion seems perfectly reasonable.

    -miles

    --
    Americans are broad-minded people. They'll accept the fact that a person can
    be an alcoholic, a dope fiend, a wife beater, and even a newspaperman, but if
    a man doesn't drive, there is something wrong with him. -- Art Buchwald
     
    Miles Bader, Oct 9, 2011
    #18
  19. Stefan Ram

    Stefan Ram Guest

    Miles Bader <> writes:
    >Paul Brettschneider <> writes:
    >>Either treat bools like a normal integer type (with a size optimized for the
    >>use as flag, e.g. char for x86, int for RISC) or make the conversion non-
    >>explicit. But I understand that the reasons for the standard compliant
    >>behaviour are historical and this has been discussed at length before. One
    >>of the terrible legacy things we have to live with.

    >Wait, why is it "terrible"? This conversion seems perfectly reasonable.


    Yes, the canonical conversion semantics has to be

    []( int const i ){ return i ? true : false; }

    , since this naturally agrees with the identity

    []( bool const b ){ return b ? true : false; }
     
    Stefan Ram, Oct 9, 2011
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page