Is it better to use #define or const int for constants?

Question

Arduino is an odd hybrid, where some C++ functionality is used in the embedded world—traditionally a C environment. Indeed, a lot of Arduino code is very C like though.

C has traditionally used #defines for constants. There are a number of reasons for this:

1. You can't set array sizes using const int.
2. You can't use const int as case statement labels (though this does work in some compilers)
3. You can't initialize a const with another const.

You can check this question on StackOverflow for more reasoning.

So, what should we use for Arduino? I tend towards #define, but I see some code using const and some using a blend.

• ratchet freak: a good optimizer will render it moot
• Cybergibbons: Really? I don't see how a compiler is going to resolve things like type safety, not being able to use the to define array length and so on.
• SDsolar: I agree. Plus, if you look at my answer below, I demonstrate that there are circumstances when you don't really know which type to use, so #define is the obvious choice. My example is in naming Analog pins - like A5. There is no appropriate type for it that could be used as a const so the only choice is to use a #define and let the compiler substitute it as text input before interpreting the meaning.

Answer 1

It's important to note that const int does not behave identically in C and in C++, so in fact several of the objections against it that have been alluded to in the original question and in Peter Bloomfields's extensive answer are not valid:

• In C++, const int constants are compile time values and can be used to set array limits, as case labels, etc.
• const int constants do not necessarily occupy any storage. Unless you take their address or declare them extern, they will generally just have a compile time existence.

However, for integer constants, it might often be preferable to use a (named or anonymous) enum. I often like this because:

• It's backward compatible with C.
• It's nearly as type safe as const int (every bit as type safe in C++11).
• It provides a natural way of grouping related constants.
• You can even use them for some amount of namespace control.

So in an idiomatic C++ program, there is no reason whatsoever to use #define to define an integer constant. Even if you want to remain C compatible (because of technical requirements, because you're kickin' it old school, or because people you work with prefer it that way), you can still use enum and should do so, rather than use #define.

• Peter Bloomfield: You raise some excellent points (especially about the array limits -- I hadn't realised the standard compiler with Arduino IDE supported that yet). It's not quite correct to say that a compile-time constant uses no storage though, because its value still has to occur in code (i.e. program memory rather than SRAM) anywhere that it's used. That means it impacts available Flash for any type that takes up more space than a pointer.
• Cybergibbons: "so in fact several of the objections against it that have been alluded to in the original question" - why are they not valid in the original question, as it is stated these are constraints of C?
• microtherion: @Cybergibbons Arduino is based on C++, so it's not clear to me why C only constraints would be pertinent (unless your code for some reason needs to be compatible with C as well).
• microtherion: @PeterR.Bloomfield, my point about constants not requiring extra storage was confined to const int. For more complex types, you're right that storage may be allocated, but even so, you're unlikely to be worse off than with a #define.

Answer 2

EDIT: microtherion gives an excellent answer which corrects some of my points here, particularly about memory usage.

---

As you've identified, there are certain situations where you're forced to use a #define, because the compiler won't allow a const variable. Similarly, in some situations you're forced to use variables, such as when you need an array of values (i.e. you can't have an array of #define).

However, there are many other situations where there isn't necessarily a single 'correct' answer. Here are some guidelines which I would follow:

Type safety
From a general programming point-of-view, const variables are usually preferable (where possible). The main reason for that is type-safety.

A #define (preprocessor macro) directly copies the literal value into each location in code, making every usage independent. This can hypothetically result in ambiguities, because the type may end up being resolved differently depending on how/where it's used.

A const variable is only ever one type, which is determined by its declaration, and resolved during initialisation. It will often require an explicit cast before it will behave differently (although there are various situations where it can safely be implicitly type-promoted). At the very least, the compiler can (if configured correctly) emit a more reliable warning when a type issue occurs.

A possible workaround for this is to include an explicit cast or a type-suffix within a #define. For example:

#define THE_ANSWER (int8_t)42
#define NOT_QUITE_PI 3.14f

That approach can potentially cause syntax problems in some cases though, depending on how it's used.

Memory usage
Unlike general purpose computing, memory is obviously at a premium when dealing with something like an Arduino. Using a const variable vs. a #define can affect where the data is stored in memory, which may force you to use one or the other.

• const variables will (usually) be stored in SRAM, along with all other variables.
• Literal values used in #define will often be stored in program space (Flash memory), alongside the sketch itself.

(Note that there are various things which can affect exactly how and where something is stored, such as compiler configuration and optimisation.)

SRAM and Flash have different limitations (e.g. 2 KB and 32 KB respectively for the Uno). For some applications, it's quite easy to run out of SRAM, so it can be helpful to shift some things into Flash. The reverse is also possible, although probably less common.

PROGMEM
It's possible to get the benefits of type-safety while also storing the data in program space (Flash). This is done using the PROGMEM keyword. It doesn't work for all types, but it's commonly used for arrays of integers or strings.

The general form given in the documentation is as follows:

dataType variableName[] PROGMEM = {dataInt0, dataInt1, dataInt3...}; 

String tables are a bit more complicated, but the documentation has full details.

Answer 3

For variables of a specified type which are not altered during execution, either can usually be used.

For Digital pin numbers contained in variables, either can work - such as:

const int ledPin = 13;

But there is one circumstance where I always use #define

It is to define analog pin numbers, since they are alphanumeric.

Sure, you can hard-code the pin numbers as a2, a3, etc. all throughout the program and the compiler will know what to do with them. Then if you change pins then each use would need to be changed.

Moreover, I always like to have my pin definitions up at the top all in one place, so the question becomes which type of const would be appropriate for a pin defined as A5.

In those cases I always use #define

Voltage Divider Example:

//
// read12 Reads Voltage of 12V Battery
//
// SDsolar 8/8/18
//
#define adcInput A5 // Voltage divider output comes in on Analog A5
float R1 = 120000.0; // R1 for voltage divider input from external 0-15V
float R2 = 20000.0; // R2 for voltage divider output to ADC
float vRef = 4.8; // 9V on Vcc goes through the regulator
float vTmp, vIn;
int value;
.
.
void setup() {
.
// allow ADC to stabilize
value=analogRead(adcPin); delay(50); value=analogRead(adcPin); delay(50);
value=analogRead(adcPin); delay(50); value=analogRead(adcPin); delay(50);
value=analogRead(adcPin); delay(50); value=analogRead(adcPin);
.
void loop () {
.
.
 value=analogRead(adcPin);
 vTmp = value * ( vRef / 1024.0 ); 
 vIn = vTmp / (R2/(R1+R2)); 
 .
 .

All the setup variables are right at the top and there is never going to be a change to the value of adcPin except at compile time.

No worries about what type adcPin is. And no extra RAM is used in the binary to store a constant.

The compiler simply replaces each instance of adcPin with the string A5 before compiling.

---

There is an interesting Arduino Forum thread that discusses other ways to decide:

#define vs. const variable (Arduino forum)

Excertps:

Code substitution:

#define FOREVER for( ; ; )
FOREVER
 {
 if (serial.available() > 0)
 ...
 }

Debugging code:

#ifdef DEBUG
 #define DEBUG_PRINT(x) Serial.println(x)
#else
 #define DEBUG_PRINT(x)
#endif

Defining true and false as Boolean to save RAM

Instead of using `const bool true = 1;` and same for `false`
#define true (boolean)1
#define false (boolean)0

---

A lot of it comes down to personal preference, however it is clear that #define is more versatile.

• Edgar Bonet: In the same circumstances, a const will not use more RAM than a #define. And for the analog pins, I would define them as const uint8_t, although const int would make no difference.
• Edgar Bonet: You wrote "a const doesn't actually use more RAM [...] until it is actually used". You missed my point: most of the time, a const does not use RAM, even when it is used. Then, "this is a multipass compiler". Most importantly, it is an optimizing compiler. Whenever possible, constants get optimized into immediate operands.

Answer 4

1. You can't set array sizes using const int.

   You can with constexpr int:

   constexpr auto size{ 15 };
   int array[size]{};
   

2. You can't use const int as case statement labels (though this does work in some compilers)

   Again, you can with constexpr int:

   constexpr auto zero{ 0 };
   constexpr auto one{ 1 };
   int number{ 1 };
   switch (number)
   {
   case zero: Serial.println("zero!"); break;
   case one: Serial.println("one!"); break;
   default: Serial.println("neither!"); break;
   }
   

3. You can't initialize a const with another const.

   You can even initialize a constexpr with another constexpr:

   constexpr int x{ 1 };
   const int y{ x };
   constexpr int z{ x };
   

Furthermore, constexpr guarantees that the variable gets evaluated at compile-time, unlike const. constexpr also doesn't have some of the disadvantages that preprocessor macros have^(learncpp):

1. Debuggers like Visual Studio's don't let you watch preprocessor macros.
2. Macros can conflict with normal code.
3. Macros don't have scope, which increases the chance of naming conflicts.