Boolean and Integer conversion error

UncleRonin

Well-known member
Joined
Feb 28, 2006
Messages
230
Location
South Africa
Programming Experience
5-10
I'm not sure if anyone has come across this before but I'm getting some very strange conversions between Booleans and Integers...

In all of my past projects where I've done conversion between these two data types an Integer with the value of 1 has always mapped to a Boolean with the value of True. And an Integer with the value of 0 has always mapped to a Boolean with the value of False. All of a sudden on two different PC's and all projects a Boolean with the value of True maps to an Integer with the value of -1 now!

In plenty of languages 0 is False and any other value is True but whereas True will always convert to 1 now it converts to -1 instead. Can anyone explain to me why this might happen?
 
You shouldn't be switching between boolean and integer in the first place. Secondly in all of the languages I've programmed in (vb4, vb6, all of .Net, Access 2002/2003/2007) True has always had an internal value of -1.

What's the code you're using to switch between boolean and integer?
 
I use implicit conversion between the two, like the following...

VB.NET:
Dim A as Boolean = True
Dim B as Integer = A

Wherever I've used it in the past it has always been a 0-False, 1-True conversion and it worked 100% on that basis. Then yesterday when I went in to do some after hours work I kept getting strange errors in my log and when I traced it I was lank surprised to see that Integer B was set to -1.

I mean in terms of bits a 1 always represents True. In SQL Server (2005 specifically in this case, can't remember others) a boolean field always returns a 1 or a 0 and never a -1 or a 0. In every other language I've used (C++ and that lot) true is 1. And in the past my VB.NET code has been the same... I seriously didn't pull this outta thin air!:eek:

Something off topic but I've also noticed something strange where an enumeration which is obviously an Integer generates an error when using .ToString("X2") where in any other circumstance Integer.ToString("X2") works perfectly fine.
 
Not sure why, but how about..


Dim a as boolean = true
Dim b as integer =int(a)

I don't know exactly why this works, but you are getting the integer of 'a' , then assigning its value to b. Rather than trying to make b = a boolean type.


??? Not sure if this is a professional fix however.


Just for reference, your example does the same on mine, it returns -1
 
Hello UncleRonin.

I came across this too, and just figured that every value which is not 0 is considered True. However, you're right, Boolean to Int is mapped as -1 (unlikely Boolean to anything else, where it's always considered as MaxValue (for Unsigned) and MinValue for signed types).

Bobby
 
First of all, you should turn Option Strict On and use explicit conversion to convert the Boolean variable to an Integer type.

The following code returns a 1:

Dim a As Boolean = True
Dim b As Integer
b = Convert.ToInt32(a)
Console.WriteLine(b)
 
I've got an idea!! How about we read the documentation?
MSDN said:
Type Conversions
When Visual Basic converts numeric data type values to Boolean, 0 becomes False and all other values become True. When Visual Basic converts Boolean values to numeric types, False becomes 0 and True becomes -1.

When you convert between Boolean values and numeric data types, keep in mind that the .NET Framework conversion methods do not always produce the same results as the Visual Basic conversion keywords. This is because the Visual Basic conversion retains behavior compatible with previous versions. For more information, see Troubleshooting Data Types.
So, Microsoft has told you that this is the case and it's even provided troubleshooting information for you. Of course, if noone ever bothers to read the Help then it's all for nought.

The reason that True implicitly converts to -1 is that .NET Booleans are 32-bit values. False contains 32 0's and True contains 32 1's. The Integer type is 32 bits wide too. Negative Integer values are stored as their 2's complement, so -1 is represented by 32 1's. It should be no shock, then that converting 32 1's from Boolean to Integer results in the value -1. Only languages that store boolean values as a single bit will convert True to 1.
 
Okay, now that was an answer that explains the conversion business quite nicely. I still don't particularly like the fact that it converts to -1 but at least now I know why :p

As for setting Option Strict On and using explicit conversion I disagree. Yes, it prevents all sorts of baddies from happening but so does testing and planning your code. With that On things get lank verbose and the flexibility of the language (which is a big reason it's so popular) vanishes. There are times when it makes sense like for debugging and whatnot but it's just so... 'old' if you know what I mean? Plus it's disabled by default so MS says so! :D
 
Okay, now that was an answer that explains the conversion business quite nicely. I still don't particularly like the fact that it converts to -1 but at least now I know why :p

As for setting Option Strict On and using explicit conversion I disagree. Yes, it prevents all sorts of baddies from happening but so does testing and planning your code. With that On things get lank verbose and the flexibility of the language (which is a big reason it's so popular) vanishes. There are times when it makes sense like for debugging and whatnot but it's just so... 'old' if you know what I mean? Plus it's disabled by default so MS says so! :D
And with C# Option Strict is On by default, yet VB and C# are still "butting heads", explain that with Option Strict turned Off.

I've been under the impression that MS has vb's option strict turned off by default to help those coming from vb6, but ultimately once the vb6 person gets comfortable with .Net they'll be turning strict on. At least that's the feeling I've gotten from reading MS articles over the last 5 years.
 
Okay, now that was an answer that explains the conversion business quite nicely. I still don't particularly like the fact that it converts to -1 but at least now I know why :p

As for setting Option Strict On and using explicit conversion I disagree. Yes, it prevents all sorts of baddies from happening but so does testing and planning your code. With that On things get lank verbose and the flexibility of the language (which is a big reason it's so popular) vanishes. There are times when it makes sense like for debugging and whatnot but it's just so... 'old' if you know what I mean? Plus it's disabled by default so MS says so! :D
With Option Strict Off the same VB code will run slower, sometimes much slower, than with Option Strict On because the compiler will add lots of type-checking code. No amount of planning and testing can change that. VB.NET is inherently a strongly-typed language and Option Strict Off mangles it into a weakly-typed one. Having Option Strict Off by default is good for those coming from VB6 or starting from scratch because they can learn the language without worrying about some of the confusing detail. Once you are at a level that you can understand the why and how, you should turn Option Strict On and never turn it Off again except in situations that specifically need it. Option Strict Off is for amateurs, not professional developers.
 
This thread has so not been good for me :(

I've always felt that coding according to Option Strict just takes longer and kills some of the flexibility of reusing objects (as far as I can remember, don't quote me!).

I'm completely self-taught and have to bounce around between languages a lot because of work so I'm not really surprised I didn't know how the compiler handles things. I thought it compiled slower and did the type checking and conversion then instead of adding a whole bunch of checks and all that for during runtime. The same for implicit conversion since it's pretty obvious at compile time what the proposed conversion is so I thought it would do the conversion then and be equivalent to the code used for explicit conversion.

Learned something new did I (again!). Now I have the urge to go and turn that horrible thing on and recode... geh.

I would still like to know why an Enum (which is an Integer) has to be cast to an Integer before certain calls like .ToString("X2") but that is off topic.

Anyways, shot guys for all the help and the explanations. Managed to learn a bunch of stuff I had never heard of before :)
 
Back
Top