Best coding practice.

jraskell:
In C++, int values will be automatically cast to bool values

You probably mean it correctly but the correct phrasing is
"In C++, the bool type is interchangeable with int values (casts in both direction);
In C, boolean values are int values;
in arduino, boolean value is a unsigned byte value
in arduino, bool maps to _Bool which is a native GCC type (but I'm not sure what it translates to)"
from the arduino code:

typedef uint8_t boolean;

from Boolean data type - Wikipedia

Standard C (since C99) and several dialects of C such as and Objective-C provide definitions of a Boolean type as an integer type and macros for "false" and "true" as 0 and 1, respectively. However, the initial standards for the C language (1972) provided no Boolean type, and to this day Boolean values are commonly represented by integers (ints) in C programs. The comparison operators ('>', '==', etc.) are defined to return a signed integer (int) result, either zero (for false) or 1 (for true). The same convention is assumed by the logical operators ('&&', '||', '!', etc.) and condition-testing statements ('if', 'while'). Thus logical values can be stored in integer variables, and used anywhere integers would be valid, including in indexing, arithmetic, parsing, and formatting. This approach ("Boolean values are just integers") has been retained in all later versions of C.

C++ has a separate Boolean data type ('bool'), but with automatic conversions from scalar and pointer values that are very similar to those of C. This approach was adopted also by many later languages, especially by some scripting ones such as AWK and Perl. One problem with this approach is that the tests if(t==TRUE){...} and if(t) are not equivalent. Python has a related situation, where the Boolean type, bool is a subtype of the integer type, int, and Booleans False and True act as 0 and 1, respectively, in arithmetic contexts.

The Pascal language (1978) introduced the concept of programmer-defined enumerated types. A built-in Boolean data type was then provided as a predefined enumerated type with values FALSE and TRUE. By definition, all comparisons, logical operations, and conditional statements applied to and/or yielded Boolean values. Otherwise, the Boolean type had all the facilities which were available for enumerated types in general — such as ordering and use as indices. On the other hand, the conversion between Booleans and integers (or any other types) still required explicit tests or function calls, as in ALGOL 60. This approach ("Boolean is an enumerated type") was adopted by most later languages which had enumerated types, such as Modula, Ada and Haskell.

After enumerated types (enums) were added to the ANSI version of C (1989), many C programmers got used to defining their own Boolean types as such, for readability reasons. However, enumerated types are equivalent to integers according to the language standards; so the effective identity between Booleans and integers is still valid for C programs.

but really this is splitting hairs.
Because there are many flavors (typedef/define/class) and in the end -as we are talking about code compatibility when using arduino- it hardly matters.

As to the original question about coding practice
I prefer
return true/false
to
return 0/1
when defining the method as boolean

but I quite often write
return Value>limit;

my most important coding practice rule is :"if you read this code in lets say 3 months from now; would you still understand what it does?"
If the answer is yes: go for it.

Best regards
Jantje

Jantje:
in arduino, bool maps to _Bool which is a native GCC type (but I'm not sure what it translates to)"
from http://en.wikipedia.org/wiki/Boolean_data_type

Standard C (since C99) and several dialects of C such as and Objective-C provide definitions of a Boolean type as an integer type and macros for "false" and "true" as 0 and 1, respectively. However, the initial standards for the C language (1972) provided no Boolean type, and to this day Boolean values are commonly represented by integers (ints) in C programs. The comparison operators ('>', '==', etc.) are defined to return a signed integer (int) result, either zero (for false) or 1 (for true). The same convention is assumed by the logical operators ('&&', '||', '!', etc.) and condition-testing statements ('if', 'while'). Thus logical values can be stored in integer variables, and used anywhere integers would be valid, including in indexing, arithmetic, parsing, and formatting. This approach ("Boolean values are just integers") has been retained in all later versions of C.

C++ has a separate Boolean data type ('bool'), but with automatic conversions from scalar and pointer values that are very similar to those of C. This approach was adopted also by many later languages, especially by some scripting ones such as AWK and Perl. One problem with this approach is that the tests if(t==TRUE){...} and if(t) are not equivalent. Python has a related situation, where the Boolean type, bool is a subtype of the integer type, int, and Booleans False and True act as 0 and 1, respectively, in arithmetic contexts.

The Pascal language (1978) introduced the concept of programmer-defined enumerated types. A built-in Boolean data type was then provided as a predefined enumerated type with values FALSE and TRUE. By definition, all comparisons, logical operations, and conditional statements applied to and/or yielded Boolean values. Otherwise, the Boolean type had all the facilities which were available for enumerated types in general — such as ordering and use as indices. On the other hand, the conversion between Booleans and integers (or any other types) still required explicit tests or function calls, as in ALGOL 60. This approach ("Boolean is an enumerated type") was adopted by most later languages which had enumerated types, such as Modula, Ada and Haskell.

After enumerated types (enums) were added to the ANSI version of C (1989), many C programmers got used to defining their own Boolean types as such, for readability reasons. However, enumerated types are equivalent to integers according to the language standards; so the effective identity between Booleans and integers is still valid for C programs.

The thing you quoted says that bool is a standard type. Where did you see that bool is typedef'd/mapped to _Bool? Neither _bool or _Bool are mentioned in the arduino libs.

WizenedEE:
The thing you quoted says that bool is a standard type. Where did you see that bool is typedef'd/mapped to _Bool? Neither _bool or _Bool are mentioned in the arduino libs.

In [your arduino location]\hardware\tools\avr\lib\gcc\avr\4.3.2\include\stdbool.h you will find

#ifndef __cplusplus

#define bool	_Bool
#define true	1
#define false	0

#else /* __cplusplus */

/* Supporting <stdbool.h> in C++ is a GCC extension.  */
#define _Bool	bool
#define bool	bool
#define false	false
#define true	true

#endif /* __cplusplus */

Which make it dependent on whether you compile as C++ or C whether it will be _Bool or bool.
I have searched for the definition of _Bool and bool in the GCC documentation and it seemed like an integer to me. But I did not find anything remotely close to a "clear answer".
As I am not using bool but boolean -and as I consider this splitting hairs- I don't really care and I did not put much effort in it as well.

Best regards
Jantje

That's not arduino, that's avr-libc.

bool, true, and false are all part of C++, but not part of C, [citation needed] but gcc has extensions to get them to work in C also. It really doesn't matter how it's done in the internal gcc libs, since they're so well integrated with the compiler itself. It's just that you said the arduino files defined them, which is not true.

boolean is completely different and I don't see why anyone would ever use it.

Back to my original post lol. So if you declare a function as a boolean then use return true or fales but if you declare the function as an byte, int, long use return 0 or 1?

@Pavilion
I would say it is a bad practice to use int/long as return value if you only have 0 and 1 to return.
Why?
Because you use more memory than needed. Actually you only need one bit. But bits are kind of hard to use so you use the smallest memory part possible being "byte". Which is 8 times more than you actually need. Making it int means 16 times more memory usage than needed, long .....
When programming for PC/MAC/Mainframe nobody will really care nowadays (it used to be different). When programming a PIC it can make a difference.

As I stated several times before :Your question is really splitting hairs. Because technically there is no difference between boolean and byte on the arduino platform. And in the end the code quality is defined by the code behaviour; which by default will be equal using byte/boolean and 0;1/true/false.
The difference is in the mind of the person that reads it. In other words in the maintainability of the code. In our minds there is a difference between 1 and true. You can say "1 volt" but you can not say "true volt". For the arduino that is the same for humans it is not.

Conclusion: If you want to write readable code:
And you want to use the human boolean concept: use boolean/bool; true and false.
And you want to use values: take the smallest (in memory occupation terms) object that fits your needs. 0->255 => byte -32767 -> 32767 => int ..... (don't forget the unsigned and signed options)
Best regards
Jantje

@WizenedEE

WizenedEE:
bool, true, and false are all part of C++, but not part of C, [citation needed]

I think the text I quoted states that: "bool, true, and false are all part of C++" and "boolean, true, and false are all part of C (since C99)"

WizenedEE:
It's just that you said the arduino files defined them, which is not true.

Can you please quote my statement that makes you think I said so?

WizenedEE:
boolean is completely different and I don't see why anyone would ever use it.

Wikipedia states "C++ has a separate Boolean data type ('bool'), but with automatic conversions from scalar and pointer values that are very similar to those of C."
You state "completely different" wikipedia states "very similar". Please take up your concerns with wikipedia so we all can learn?
Wikipedia states "One problem with this approach is that the tests if(t==TRUE){...} and if(t) are not equivalent."
Which I think is a really good reason not to use bool.
Jantje

As I stated several times before :Your question is really splitting hairs. Because technically there is no difference between boolean and byte on the arduino platform.

In some expressions, byte will be promoted to int. bool (with true and false) is a better choice. Using bool when the return value really is a boolean (true/false) value allows the compiler to perform optimizations it would otherwise not be able to perform.

[quote author=Coding Badly link=topic=122407.msg923729#msg923729 date=1347642715]
In some expressions, byte will be promoted to int. bool (with true and false) is a better choice. Using bool when the return value really is a boolean (true/false) value allows the compiler to perform optimizations it would otherwise not be able to perform.[/quote]
Coding Badly
Do you have a link to the promotion to int for byte that does not happen to bool?
Do you have a link that explains the optimizations that can happen?
Best regards
Jantje

I had hoped to learn something following this thread, but I am more confused now then before this thread was started. :~

So can someone explain it in simple words that a hardware guy could understand? What must I come away with from this topic that is important to my writing 'better' code in the future? What kind of unintended bugs could I put into my sketch if I misunderstand what is trying to be communicated here. Keep it simple and I've always found example code to be more effective then just English words, these postings will out live us all.

Lefty

Code is read more than it's written. So read-time convenience is to be favoured over write-time convenience (not my words, cfr Code Complete 2).
So using boolean and true/false is preferable because it makes the code easier to understand, IMHO.

As always, just my 2 cents.

Jantje:
Do you have a link to the promotion to int for byte that does not happen to bool?

Sorry, I do not. My gut tells me the standard leaves that to the compiler folks to decide.

Do you have a link that explains the optimizations that can happen?

Nope. Don't have that either.

I have a small amount of personal experience (but no examples at hand; too much time has passed).

Jantje:

WizenedEE:
bool, true, and false are all part of C++, but not part of C, [citation needed]

I think the text I quoted states that: "bool, true, and false are all part of C++" and "boolean, true, and false are all part of C (since C99)"

Interesting. C99 is, unfortunately, still not used all that frequently, which makes me not really think of it as C (although I'm not blaming anyone for doing so; it is indeed C)

WizenedEE:
It's just that you said the arduino files defined them, which is not true.

Can you please quote my statement that makes you think I said so?

in arduino, bool maps to _Bool which is a native GCC type (but I'm not sure what it translates to)"

WizenedEE:
boolean is completely different and I don't see why anyone would ever use it.

Wikipedia states "C++ has a separate Boolean data type ('bool'), but with automatic conversions from scalar and pointer values that are very similar to those of C."
You state "completely different" wikipedia states "very similar". Please take up your concerns with wikipedia so we all can learn?

wikipedia is talking about bool' not boolean.' Also, even if wikipedia was talking about `bool' it says ``very similar'' in respect to a different topic --- C vs C++, not bool vs int. Context is always relevant.

Wikipedia states "One problem with this approach is that the tests if(t==TRUE){...} and if(t) are not equivalent."
Which I think is a really good reason not to use bool.

They're the same if t' is a bool (assuming the capitalization issue is fixed). They may not be the same if t' is something else (like an int), which I think is a really good reason to use bool.


I'm not trying to be antagonistic; I just like correct things. And discussion.

retrolefty:
I had hoped to learn something following this thread, but I am more confused now then before this thread was started. :~

This topic has descended into a discussion of the nuances of the two languages so it's not surprising there isn't much to take away. In other words, I suspect we're all confused. :wink:

So can someone explain it in simple words that a hardware guy could understand? What must I come away with from this topic that is important to my writing 'better' code in the future?

By far, the most important thing is to write code that your future self can understand and maintain. Don't use something just because someone else claims it is the right thing to do. Very sparingly use things that you don't understand well. Write code that you can quickly understand. In other words, know thyself and code for thyself. Doing so helps now with correctness and debugging and helps later with maintenance.

The simple fact is that bool, byte, and boolean are almost perfectly interchangeable. true is almost perfectly interchangeable with 1 and false is almost perfectly interchangeable with 0. They are all just a means to an end. Use whatever works best to help you understand the code now and in the future.

What kind of unintended bugs could I put into my sketch if I misunderstand what is trying to be communicated here.

I can't think of any.

Thanks CB, I was afraid I was missing out of something important if not useful.

I fullly agree with this one. That is why I stated several times it is "splitting hairs"
Best regards
Jantje

@WizenedEE

WizenedEE:
I'm not trying to be antagonistic; I just like correct things. And discussion.

I to like correct things. That is why I don't like someone putting words in my mouth which I have not stated.
saying "in arduino, bool maps to _Bool which is a native GCC type (but I'm not sure what it translates to)"
is not the same as saying "the arduino files defined them"

Anyone who likes correct things should know so.
Jantje

Jantje:

WizenedEE:
I'm not trying to be antagonistic; I just like correct things. And discussion.

I to like correct things. That is why I don't like someone putting words in my mouth which I have not stated.
saying "in arduino, bool maps to _Bool which is a native GCC type (but I'm not sure what it translates to)"
is not the same as saying "the arduino files defined them"

Anyone who likes correct things should know so.

Can you lay off the attacks please? Let's try to keep the discussion civil.

The arduino distribution includes a lot of things. Think of it as a house. One part of the house is the compiler itself. Another is avr-libc. Think of both of those as rooms with those names. The other rooms are frequently just called "arduino," just like the house as a whole. So, when one says something is part of "arduino" they generally don't mean "part of the compiler" or "part of avr-libc." So I hope you'll understand my confusion and not think I'm "Putting words in your mouth" --- that's how I understood them.

Also, I tend to think of avr-libc as part of gcc (while that is not entirely correct, they are almost always together). So, to me, "a native GCC type" could mean one that's defined in avr-libc or gcc (although I see now that "native" probably means it's part of the compiler itself). Thus, when one says that something is mapped to a native gcc type, they generally mean that it's mapped outside of gcc itself, since the internals are largely irrelevant in this context.

_Bool is a C99 type, bool is a C++ type. Both take a single byte, same as unsigned char, signed char, and char data types. Note, _Bool is C only and bool is C++ only, unless some other include file has done a #define to map one into another. Since the Arduino IDE uses C++ for compiling .ino/.pde files, you should use the 'bool' type.

Speaking of splitting hair... Oddly, the arduino ide (I've tried 1.0.1) highlights boolean but not bool...

bools are bools.

They shouldn't really be interchangable with ints, it's one of the language compromises made for backwards compatibility with C.

I think you code will improve if you treat them as if they weren't interchangable. The compiler is perfectly capable of optimizing away statments like "if (x==1)", it output the same code as "if (x)".

I think your code will improve if you treat them as if they weren't interchangeable.

I totally agree.