Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > "bool const a( 5 )" in "Microsoft Visual Studio C++ 2010"

Reply
Thread Tools

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

 
 
Balog Pal
Guest
Posts: n/a
 
      09-29-2011
"Paavo Helde" <(E-Mail Removed)>
> "Balog Pal" <(E-Mail Removed)> wrote in news:j62hha$2sej$(E-Mail Removed):
>
>>>>> 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(: 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






 
Reply With Quote
 
 
 
 
Miles Bader
Guest
Posts: n/a
 
      09-30-2011
Jorgen Grahn <(E-Mail Removed)> 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]
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      09-30-2011
On Fri, 2011-09-30, Miles Bader wrote:
> Jorgen Grahn <(E-Mail Removed)> 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 .
 
Reply With Quote
 
Miles Bader
Guest
Posts: n/a
 
      09-30-2011
Jorgen Grahn <(E-Mail Removed)> 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.
 
Reply With Quote
 
Peter
Guest
Posts: n/a
 
      10-03-2011
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?
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      10-04-2011
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 .
 
Reply With Quote
 
Paul Brettschneider
Guest
Posts: n/a
 
      10-08-2011
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.
 
Reply With Quote
 
Miles Bader
Guest
Posts: n/a
 
      10-09-2011
Paul Brettschneider <(E-Mail Removed)> 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
 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      10-09-2011
Miles Bader <(E-Mail Removed)> writes:
>Paul Brettschneider <(E-Mail Removed)> 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; }

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
const vector<A> vs vector<const A> vs const vector<const A> Javier C++ 2 09-04-2007 08:46 PM
Should I write Visual studio 2005 or Visual studio 2003 MCSD =?Utf-8?B?VmlqYXk=?= Microsoft Certification 14 06-30-2006 09:05 AM
Is Visual Studio Team System and Visual Studio Foundation Server are same?. Thirumalai ASP .Net 0 05-22-2006 08:48 AM
visual studio .net 2003 verses visual studio .net 2002 wh ASP .Net 2 01-16-2004 04:54 PM



Advertisments