0

Why is it that some languages don't even have a boolean type (and uses a constant TRUE instead), but they have many other and modern types? Sometimes it can be trouble if you make a boolean and then realize it can have three different values or more, then it's going to be difficult if you have old data with the boolean variable. What are some other reasons to avoid boolean variables?

Related question: https://stackoverflow.com/questions/2426000/why-didnt-c-have-a-boolean-data-type-prior-to-c99

I'm thinking more of conceptual problem like undecidable cases and synchronization problems. And that a boolean often is redaundant information and therefore it can be problems and synchronization issues.

For a semaphore a boolean could be good but maybe not as an instance variable for an account whether or not the account is "P" since that may be different in different ways one might not have thought of, for example when you realize that there are not only two mutually exclusive states for what you are modelling.

Community
  • 1
Niklas Rosencrantz
  • 8,178

3 Answers3

2

I've never really heard of booleans as being "bad" - as for interfacing with languages (such as in Robbie's answer), it doesn't really matter what type you're working with, you're probably going to need some conversion somewhere.

Moving between the barriers of languages always calls for care in how the values are mapped. Passing an integer value from VBA as supposed to be representing a boolean is an amateur mistake and it should be known that explicit type casting before submitting across the boundary is a good practice. IMO, this has little to do with any specific type being not good to use (it'd be the same case if a VBA integer were passed to a C int (which is a Long in VBA) - it wouldn't make it so "integers are bad", it's just something else we have to be careful of).

I'm not even really sure how we'd work without a language that can't resolve something down to a boolean type of some sort. Every equality comparison expression returns a boolean.

Are strings bad because their low level implementation is hidden from higher level languages? Do we avoid them as such? No, we just try to be aware of the differences between languages and understand the implications and program accordingly (which usually amounts to nothing out of the oridinary). I don't see why we'd treat boolean values any differently.

jleach
  • 2,692
  • 11
  • 27
1

You can hit problems when interfacing between languages that support a boolean such as Visual Basic and legacy languages which don't.

We hit a nasty bug many years ago when a junior developer passed an integer representation of a boolean value in VB to a C DLL. The C DLL was of course expecting >=1 to be true and everything else false, but under the hood true in VB is actually -1.

EDIT:

Things get even more interesting if you have a nullable boolean as you can in C#. We've been doing our first test to a third party API just now and we are again getting -1 back in the XML response. We think that might mean true but can't be sure and the developer in question is off sunning himself somewhere. This leads to the point many here have intimated at: it isn't enough to define the type, you also need to agree on representations when those values cross boundaries. Simply saying non-zero isn't false just doesn't cut it here...

Robbie Dee
  • 9,823
1

This boolean problem is not only related to programming itself. Databases have the same issue in representing boolean values.

Example:

Where MS Access uses -1 as true or yes like VB (see Robbie's answer), MySQL assumes that all except 0 is true.

Transferring data from one database system to another or queries with keywords like true or false can result in strange things.

Clijsters
  • 128