I need to set many constants, and I was wondering which one is better, why is bettter or faster ?
This:
#define LED_WARNING 13
Or
const int LED_WARNING 13
Or this:
int LED_WARNING 13
Of the three then
const int LED_WARNING 13
is the best but
const byte LED_WARNING 13
would be better. Because it uses less memory at run time.
Then
#define LED_WARNING 13
Is good also but it simply replaces the text with the number at run time so you don't get a warning if you try and change the value of LED_WARNING in the rest of the code.
Just to bust your bubble, I prefer this:
enum PINS{
LED_WARNING = 13
};
Not really, this is equal to the define.
The const is clearly a compile time constant in this context so it is also equal... But this context only, there are various scenarios when a compiler cannot guarantee a variable is a compile time constant, and therefore may not be compiled as one.
Do not use a 'variable' type when you mean 'constant variable', i.e const int over int
thanks guys!
MarceloBoeira:
I need to set many constants, and I was wondering which one is better, why is bettter or faster ?
This:#define LED_WARNING 13Or
const int LED_WARNING = 13;Or this:
int LED_WARNING = 13;
Note, I have fixed the typos you had in the above examples.
For C++ (which is used in the Arduino), there is little difference between using a #define or using a const int.
The difference is using #define allows you to use the value in an #if line. This can be useful if you want to optionally enable code when you are compiling it. For example, for my steampunk camera, I sometimes use an Arduino that is connected to a telegraph key to fire the camera. I have an option in the source to enable adding a buzzer that sounds out "FIRE" in morse code when the camera is fired. If I don't have the buzzer connected, I can change the #define to 0, so that it doesn't include the Morse code version.
#define HAVE_MORSE 1
// ...
#if HAVE_MORSE
// Arduino Morse Library
// Written by Erik Linder SM0RVV and Mark VandeWettering K6HX
#include "Morse.h"
// Morse speed
const int morse_speed_light = 12;
const int morse_speed_buzzer = 24;
Morse morse_buzzer_or_light (pin_buzzer, morse_speed_buzzer, 1);
#endif
If you were programming on a system that allowed use of a source code debugger like gdb, using const int would be an advantage since it would be available to the debugger for use in expressions, while #define's are not typically available.
If you use a non-const int declaration, the compiler has to assume that the value might be changed, and create a variable at runtime, and load it up. You would not be able to use this value for array bounds of static/global definitions. For const and #define declarations, the compiler does not emit a variable, and can further optimize things if it knows the value is constant. It looks like the SDfat library has special optimizations if it knows the pin is constant.
Finally, if you were programming in C instead of C++, under C rules, you could not use a const int as an array bound, and the compiler would typically create a read-only variable for it.
Grumpy_Mike:
Of the three thenconst int LED_WARNING 13is the best but
const byte LED_WARNING 13would be better. Because it uses less memory at run time.
Under C rules that would be correct. However, that is one of the differences between C and C++, where in C++ the compiler must treat const int = ; as a compile time constant if is a compile time constant. If is not a compile time constant, then the compiler just treats as a variable that cannot be modified in the current scope.
For const and #define declarations, the compiler does not emit a variable...
True and while it doesn't matter much in the Arduino IDE environment, this also means you cannot observe these data items with a debugger at runtime like you can with "true" variables.
The thing I always point out:
"const int" is strongly typed, "#define" is not.
Using "const" can both warn you if you're doing something wrong - plus it can help the compiler to do maths properly. For instance, take this little snippet using floats:
#define MYDIV 3
const float mydiv = 3;
void setup()
{
Serial.begin(9600);
}
void loop()
{
float sum;
unsigned int randomnumber = random(1,50000);
sum = randomnumber / MYDIV;
Serial.print(sum);
Serial.print(" ");
sum = randomnumber / mydiv;
Serial.println(sum);
delay(1000);
}
Get a random number, divide it by three. Simple enough...
Both the #define and the const are set to 3, so you'd expect the same results, yes? No.
#define is a integer of 3, but the const is a float of 3. An integer divided by an integer is an integer - regardless of the destination variable type, but an integer divided by a float yields a float. The output of that little sketch is:
5602.00 5602.67
10299.00 10299.67
10842.00 10842.33
4452.00 4452.67
10604.00 10604.33
6892.00 6892.33
9855.00 9855.00
10012.00 10012.00
2366.00 2366.67
9285.00 9285.00
10304.00 10304.00
...
See those discrepancies? The column on the right is the right value, the column on the left is not what we want.
Tip: You can think of mathematical operators as functions. a / b can be thought of as div(a,b). Divide two integers, and the function prototype would look like: int div(int a, int b). Divide an int by a float and it may look like: float div(int a, float b).
That's the advantage of the strongly typed constants over the untyped #define values.
That's the advantage of the strongly typed constants over the untyped #define values.
#defines are as typed as you define them, or you let the compiler decide..
see extended code sample here
#define MYDIV 3
#define MYTHREE 3.0
#define LONGTHREE 3UL
#define SHORTTHREE ((byte)3)
const float mydiv = 3;
void setup()
{
Serial.begin(9600);
}
void loop()
{
float sum;
unsigned int randomnumber = random(1,50000);
sum = randomnumber / MYDIV;
Serial.print(sum);
Serial.print(" ");
sum = randomnumber / MYTHREE;
Serial.print(sum);
Serial.print(" ");
Serial.print(sizeof(MYDIV));
Serial.print(" ");
Serial.print(sizeof(MYTHREE));
Serial.print(" ");
Serial.print(sizeof(LONGTHREE));
Serial.print(" ");
Serial.print(sizeof(SHORTTHREE));
Serial.print(" ");
sum = randomnumber / mydiv;
Serial.println(sum);
delay(1000);
}
Note that now with C++11 we can also use constexpr as well. That keyword can be used for any data that can be evaluated and assigned at compile-time. In most contexts it will be treated exactly like const for purposes of producing final compiled code.
The extra-special thing about constexpr is that not only can you use it in defining data, you can also use it to define compile-time functions. Such functions can be used in the pre-compiler function static_assert. As with the #if directive, the static_assert function doesn't produce any compiled code itself, but it does allow you to examine things at compile time such as the contents of arrays defined with constexpr. Also, static_assert allows you to compare float values, something which you can't do in #if at all.
Anyway, generally-speaking the compiler will do its best to treat values as constants when it can, to improve code performance and/or reduce size, depending on your compiler settings. Even when you don't use const the compiler can tell when a variable is never changed, and may optimize it into a constant anyway. The one extra thing to remember for AVR is that when you want to store things in PROGMEM (within functions) you should use static const and not just const.
BOEIRA:
I need to set many constants, and I was wondering which one is better, why is bettter or faster ?
This:#define LED_WARNING 13Or
const int LED_WARNING 13Or this:
int LED_WARNING 13
Well, since the last two will cause compile time errors, they may be consider the fastest. But, perhaps not the result you're looking for .....
Seriously, I highly doubt that any (valid) method will make the slightest bit of (noticeable) difference in the execution time of your code.