The truth about true

[EscapeCharacter]

ive been wondering which would be more appropriate when dealing with c++ and functions that return 1 or 0, true or false.
would it be more *standard* to have it return and int and check for 1 or 0, or to have it return bool and check for true or false? i know it doesnt really matter because they both mean the same thing but i would like to get use to the standard way of doing things...

[bwkaz]

AFAIK, in C++, if you're doing some sort of Boolean operation, a bool type is appropriate and, more or less, standard.

In plain C, where the "bool" type doesn't exist, you use ints instead, 0 is false, and anything else is true.

But I could be mistaken. This is just the way I do it, most of the time.

[sans-hubris]

The C++ way would be to use the bool type. For most compilers, this is little more than a typedef to an int.

Making use of the bool lets you take advantage of the compiler's type checking. If a function is supposed to return a bool, but it in some cases returns an int, the compiler can give you a warning (NB, not an error, just a warning that you're not returning what you said you'd return.)

[EscapeCharacter]

ok sounds good, i guess it wont hurt me to type four characters instead of three :)

[phubuh]

Originally posted by sans-hubris
The C++ way would be to use the bool type. For most compilers, this is little more than a typedef to an int.
Why not typedef it to, say, char? Four bytes when you need one bit seems a bit... overkill.

[sans-hubris]

Originally posted by phubuh
Why not typedef it to, say, char? Four bytes when you need one bit seems a bit... overkill. True (no pun intended), and it may well indeed be so. However, all primitive types, with the exceptions of floats and doubles, are all very similar to an int, so I'm sure (but I don't actually know) that the code in the compilers that handles those things is possibly the same for all of them, except they are made to handle them at different sizes. Or at least that's the way I would implement it.

[bwkaz]

Originally posted by phubuh
Why not typedef it to, say, char? Four bytes when you need one bit seems a bit... overkill. Data alignment and size constraints at the processor level.

On most 32-bit machines, it is either flat-out required (MIPS), or you just get a lot better performance (IA-32) when all memory accesses are aligned on a 32-bit boundary. Now alignment doesn't really matter, because no matter how many bytes you use (up to 32), you'll still be wasting all but one of them.

But typedefing to a char also makes the machine load or store only 8 bits from or to memory, which may require special (slightly slower) instructions on some architectures. Since the number of bits in an int is generally the same as the optimal alignment, and the default operand size, it makes things (probably) slightly faster on these architectures if you use an int.

Now, this doesn't apply to all architectures, of course, but I think it does apply to the majority of them.

[phubuh]

Oh, okay. Thanks for clearing that up.