why use bool

I just tried compiling two different versions of the same file.

int main()
{
	char first = (char)true;

	return 0;
}
 

and

int main()
{
	bool first = true;

	return 0;
}
 

I checked the assembly and both files are the same. Used Microsoft Visual C++ 6.0.



-Agent1

BOOL is a win32 typedef for int, bool is a native 8 bit type. Always 32 bit numbers because thats the native size for the CPU. the return statement puts a number in EAX (or AL for 8 bit) which is then checked by the calling function right after. There is no slowdown using ints. Writing ints to memory is also not slower becuase the compiler aligns all the variables to 32-bit boundaries anyways (unless you have 2 chars in a row, then you save space by using chars)

Also don''t check if a variable ==TRUE, use !=FALSE. Checking if it non-zero is a better practice then checking if it is 1

As for coding style there is nothing wrong with using bool, BOOL, int or a char, just be consistent. The speed really is no different nor does it matter at all

BOOL was designed for windows and is a simple typedef int BOOL; (or perhaps it was a #define...)
It was made because on invalid pointers the functions would return -1 and not true or false.(or at least this is what Ive heard)

and the size of bool is just 1 bit, or perhaps this is compiler specific?

[edited by - angry on July 11, 2003 7:08:18 PM]

Int is a type whose size is based in architecture characteristic. In fact the size of int is equal to the size of adressing word of the processor(pointer). Since moderns PCs are 32 bit machines.. that use 32 bit pointers, int is sized as 4 bytes. In an Itanium an int is 64 bit long. In fact in an Itanium an Int is bigger than a long

bool may be implemented even as a single bit if the hardware architecture supports it. In ia32 code the 32 bit fixed notation is the fastest type(due to memory alignment stuff), so that it''s mostly used to represent bools. A compiler may implemnt it as a 16 bit value... or 8 bit... etc...

quote:

---

Original post by OldMan__
In fact in an Itanium an Int is bigger than a long

---

That would, if it were true, be a violation of the C++ standard. 3.9.1.2 states:

There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this list, each type provides at least as much storage as those preceding it in the list.

---

AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.

quote:

---

Original post by PaulCesar
Amoung them the fact that i do not use the type bool (BOOL) to signify values that could be true or false. My justification to him was that bool values are actualy of type __int32 (int) whereas i would use an __int8 (char) value to signify my boolean values.

---

I don''t know if that''s true, but to "never" use bool looks an awful lot like premature optimization to me. And you know what they say about premature optimization...

Cédric

Using ''bool'' instead of ''int'' has one very valuable advantage: more readable code.

quote:

---

Original post by Cybertron
BOOL is a win32 typedef for int, bool is a native 8 bit type.

---

A bool is guaranteed to be at least as big as a char (which may or may not be 8 bits), and no larger than a long (whose size may or may not differ from that of a char). See Stroustrup, TCPL, 4.6.

Andy pinned the tail on. That's a very big reason to use bool. Would you rather see integers or booleans? Makes your code a lot easier to understand.

Also, if your worried about the size or type definition, why not make your own?

#define MyBool char
Or...
#define MyBool int
Or...
Whatever

#define MyTrue (1==1)
#define MyFalse !MyTrue

Then you don'e have to woory about it.

-UltimaX-

"You wished for a white christmas... Now go shovel your wishes!"

[edited by - UltimaX on July 11, 2003 7:59:35 PM]

quote:

---

Original post by UltimaX
#define MyBool char
Or...
#define MyBool int
Or...
Whatever

#define MyTrue (1==1)
#define MyFalse !MyTrue

---

Urk, #defines. If you wanted a "smaller" alternative to bools, you should make your own struct MyBool, so that you could control the implicit conversions and define the == operator.

Cédric

Sorry if I''m taking this slightly off topic, but...

Why can''t bools be 1 bit? They only need 1 bit, right? 2 possible values, 0 or 1 (true or false).

quote:

---

Original post by Ironica
Why can''t bools be 1 bit? They only need 1 bit, right? 2 possible values, 0 or 1 (true or false).

---

The smallest addressable unit on a computer is a byte. It would be very inefficient to address single bits.

quote:

---

Original post by Ironica
Sorry if I''m taking this slightly off topic, but...

Why can''t bools be 1 bit? They only need 1 bit, right? 2 possible values, 0 or 1 (true or false).

---

Because the smallest addressable unit is typically much larger than one bit. On most systems I know of, it''s 8 bits, then labelled a byte. Since you cannot address an individual bit, you cannot allocate just one bit of memory, and therefore, the size of a variable cannot be one bit.

Of course, you can use bit fields in C and C++ to achieve the effect of less-than-byte-sized variables, but this must surely involve some shifting and trickery and must therefore be much slower.

As the question applies to C++: A bool is guaranteed to be at least as large as a char. A char, moreover, is guaranteed to be at least 8 bits. Ergo, a bool must be at least 8 bits.

heh, i started a war.... actualy i find that my code is clean enough, as bool and char in my head are already set to represent similar sets. Oncemore, if i needed an aditional return in the future, it would not be impossable to add it to a function. (And not have to change the architecture)

In modern computers, i believe using an array of bools is slightly faster than bitfields. Historically, the opposite was true. I doubt that an array of bools is much faster, however. It still requires a pointer dereference. A bit field will usually require a single bitwise operation. I, personally, think bitfields can be more readable. Would you rather

if(inventory[0] == 1)
/* do stuff */

-or-

if(inventory & SWORD)
/* do stuff */

You can make the former more readable if you do some complicated stuff under the hood, but that seems like a waste of effort for a marginal speedup. I guess i''m just old fashioned.

Big difference: vector<bool> vs. vector<int>. A specialization of the vector template is available for the bool datatype, and it can help you save a tremendeous amount of memory for large bool vectors, by storing them as bit streams. In other words: vector<bool> treats each bool as a single bit, packing 32 bools into a single int. See TC++PL3 section 16.3.11.

Efficiency is pretty good: eventhough bit addressing is used (which is not as slow as some people implied), this approach saves a lot of cache misses on the array.


[edited by - Yann L on July 11, 2003 9:12:02 PM]

quote:

---

Original post by kdogg
In modern computers, i believe using an array of bools is slightly faster than bitfields. Historically, the opposite was true. I doubt that an array of bools is much faster, however. It still requires a pointer dereference. A bit field will usually require a single bitwise operation. I, personally, think bitfields can be more readable. Would you rather

if(inventory[0] == 1)
/* do stuff */

-or-

if(inventory & SWORD)
/* do stuff */

You can make the former more readable if you do some complicated stuff under the hood, but that seems like a waste of effort for a marginal speedup. I guess i''m just old fashioned.

---

Using bits is better I would assume. Using an array it has to read and test one byte per item. For flags it does one read into a register and does multiple tests on it. Of cource if the code run by the IF statement is not trivial trhe register is trashed and the speed wouldn''t matter

It does save space using bits. If you are passing it to a function 32 BITS is way better then 32 BYTES!

You learn a lot of cool things with assembly, no programmer should be without it!

I've done some experimenting and is seems like there is a very slight speed advantage for an array of ints as opposed to a bitfield. Even so, i still use bitfields. I find them more readable and 8 times smaller. Why waste memory when there's a perfectly good solution that conserves it? Bitwise operations are part of every processor's instruction set so you know it'll be fast no matter what machine you run it on and no matter what compiler you use.

[edited by - kdogg on July 11, 2003 10:19:01 PM]

quote:

---

Original post by Arild Fines

quote:

---

Original post by OldMan__
In fact in an Itanium an Int is bigger than a long

---

That would, if it were true, be a violation of the C++ standard. 3.9.1.2 states:

There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this list, each type provides at least as much storage as those preceding it in the list.

---

AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.

---

and where do wyou see long (alone) there?

There are 2 levels in the standard. One that is related to architecture (int, char...) other related to ..well nothin.. (short, long...) these last may also be used as qualifiers for the first ones. In fact long int is still 64 bit, since the c++ standrd do not support 128 bit stuff. But GNU extension to C++ may handle it in g++ compiler.

And yest it IS true.. I already tested that in an Itanium.