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

[Stefan Ram]

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.«

?

 

[Alf P. Steinbach]

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

 

[Balog Pal]

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.

 

[Paul Brettschneider]

. 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.

 

[Edek]

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

 

[Jorgen Grahn]

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

 

[Fulvio Esposito]

mmm in the recently released Developer Preview of
visual Studio 11 the bug is still present! Very
disappointing!!

Cheers,
Fulvio Esposito

 

[Balog Pal]

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.

 

[Krice]

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!

 

[Geoff]

I have confirmed this behavior with MSVC 10.0.



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.

 

[Balog Pal]

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

 

[Miles Bader]

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

 

[Jorgen Grahn]

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

 

[Miles Bader]

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

 

[Peter]

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?

 

[Jorgen Grahn]

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

 

[Paul Brettschneider]

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.

 

[Miles Bader]

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

 

[Stefan Ram]

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; }