Arduino Stack Exchange is a question and answer site for developers of open-source hardware and software that is compatible with Arduino. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
a good optimizer will render it moot – ratchet freak Feb 28 '14 at 10:19
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. – Cybergibbons Feb 28 '14 at 11:27
up vote 10 down vote accepted

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.

share|improve this answer
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. – Peter R. Bloomfield Feb 28 '14 at 15:28
"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? – Cybergibbons Feb 28 '14 at 15:54
@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 Mar 1 '14 at 4:23
@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. – microtherion Mar 1 '14 at 4:27

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.

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.