Hi there,
In the Arduino Ref, the case in the switch can be either an int or a char.
2 questions :
Thanks
Meric:
is Byte is a legit type ?
No, but byte is. C++ and the Arduino programming language that is based on it are case-sensitive.
Meric:
- But, after a quick google search, Byte seems not to be part of native C, but a sort of reconstruction.
There's no magic to it. typedef is part of native C and C++:
typedef uint8_t byte;
Meric:
- Is my switch will be functional ?
Yes.
Meric:
- Is using Byte is a good design choice ?
From the standpoint of making code friendly to beginners, I think so. Compare it to the alternatives: unsigned char or uint8_t.
From the standpoint of making your code portable outside of Arduino, perhaps not so much.
I was involved in an initiative to discourage the use of the Arduino core typedef boolean in favor of the standard bool, which you can see has received official status:
boolean is a non-standard type alias for bool defined by Arduino. It’s recommended to instead use the standard type bool, which is identical.
In that case, I didn't feel that the benefits of the slightly more beginner friendly boolean outweighed the disadvantages of using a non-portable type alias. However, my feelings are different when it comes to byte.
No, but byte is. C++ and the Arduino programming language that is based on it are case-sensitive.
Sorry, a reflex to put a B for byte, and a b for bit. I'm indeed talking about byte, and I'm not trying to declare a "Byte".
typedef uint8_t byte;
That is interesting. So the uint8_t is more "native" than the byte. Out of portability matters, is using byte instead of uint8_t imply somewhere a loss of performance, or not at all ?
About the bool, I was even not aware about the "boolean" existence ^^
What kind of data is in your "byte"? There is no performance difference between 'byte', 'unsigned char' and 'uint8_t'.
uint8_t is more "native" than the byte
No, that is also a typedef.
Native variable types are described in C/C++ references like this one. Scroll down to "fundamental data types".
jremington:
No, that is also a typedef.
However, it is a standard typedef.
No, that is also a typedef.
Damned !
So the "native" type is unsigned char.
Well.
There is no performance difference between 'byte', 'unsigned char' and 'uint8_t'.
OK, the need to call a lib to pass a definition instead of use directly a native type is more or less transparent for the perf, that is your point ?
Do you mean "include a lib" and "define a type"? You have to be careful with terminology or things get confusing really fast.
Type definitions don't generate any code, they are only instructions for the compiler to handle identifiers in a certain way. So including a library that provides some type definition certainly won't impact code generation. An optimizing compiler (like AVR-GCC and most others) does not compile unused code. That also applies to libraries.
My problem with the "byte" data type is that in Java, "byte" is signed.
yes, I'm confused in the libraries mechanisms. That's my question, actually.
How does it works ? let me try something :
=> Innocently, I would say that the second one is better than the first. Perhaps I'm wrong, and difference is totally erase at compilation ?
Edit : OK, cross posted. You perfeclty answer to my not-yet-expressed question.
Type definitions don't generate any code, they are only instructions for the compiler to handle identifiers
Thanks to all,
have a nice evening, use bytes & keep safe.
Yes you are wrong. I told you already there is no difference. The inclusion with #include just pastes all the library text in front of the main program, before compilation. So by the time it sees some redefinition, it already knows the definition. Even so, it wouldn't matter when it comes to code generation because all the machinations of the compiler, including identifiers and definitions, are thrown out the window at that time.
A definitive answer to your main question, "is byte a good choice" depends on what you are doing with the data.
So this is a double-cross-edited discussion. Never try this at home.
Thank you for your cristal clear explanations.
A definitive answer to your main question, "is byte a good choice" depends on what you are doing with the data.
If you let me digress again, I need it to define constants.
// faultcase
byte faultcase;
const byte noFault = 0;
const byte msgFault = 1;
const byte parsingFault = 2;
const byte motorFault = 3;
and after, the famous switch case
switch (faultcase) {
case msgFault:
Actually, 4 bits should be sufficient for my use. As far as I know, there is no type for 4 bits. (?)
Meric:
Actually, 4 bits should be sufficient for my use. As far as I know, there is no type for 4 bits. (?)
No. Eight is as small as it gets.
The "slick" way to do that is to make an enum:
enum faultType byte (noFault , msgFault, parsingFault, motorFault);
faultType faultcase = noFault;
...
switch (faultcase) {
case msgFault:
...
So nice. I'll do that.