9

I read definitions like

const int ledPin = 9;

and also

#define ledPin 9

I know that a definition like

int ledPin = 9;

is a bad practice if you're not going to change it (which you usually won't), though I've see this several times in Arduino programs. Which one of the other two is preferred?

6

#define ledPin 9 is preferred. By doing int ledPin = 9; you will be allocating an int memory whose value is used every time you use ledPin. #define is different in the sense it doesn't allocate memory. there is no memory called ledPin. Before compiling all "ledPin"s in the code(other than strings) are replaced by 9. So basically

digitalWrite(ledPin);

becomes

digitalWrite(9);

Advantages of #define : Saves memory and since all ledPin are replaced by 9 before execution, it saves processor time.

Doesn't really matter in small codes...

  • Are embedded compilers really so bad they don't do constant folding when using const int? – Chuu Apr 27 '15 at 16:11
  • 1
    @chuu as far as I know Arduino uses gcc for avr. So it should almost definitely be optimized out. The answers here don't show much understanding of good practice in C++ – chbaker0 Apr 27 '15 at 16:55
  • 3
    in C++, const int ledPin = 9; is preferred over 2 other options. This will NOT allocate memory for an int except if you define a pointer to it somewhere, which nobody would do. – jfpoilpret Apr 27 '15 at 18:12
  • Const int does allocate memory @jfpoilpret. #define doesn't take up any memory cuz its just a symbolic name of an expression and not the name of a memory... – user8688 Apr 28 '15 at 16:59
  • Check out this link cplusplus.com/forum/beginner/28089 and see for yourself. Otherwise just perform the check with Arduino IDE: check the data size with const and with #define. – jfpoilpret Apr 28 '15 at 17:46
4

Strictly speaking, the #define approach will use slightly less memory. The difference is usually tiny though. If you need to reduce memory usage, then other optimisations would probably be far more effective.

An argument in favour of using const int is type safety. Wherever you refer to that pin number by variable, you know exactly what data type you're getting. It might be promoted/converted implicitly or explicitly by the code which uses it, but it should behave in very clear ways.

By contrast, the value in a #define is open to interpretation. The vast majority of the time, it probably won't cause you any problems at all. You just need to be a little careful if you have code which makes assumptions about the type or size of the value.

Personally, I almost always prefer type safety unless I have a very serious need to save memory.

  • I was in the #define camp until I read Peter's answer. Guess I know who will be refactoring code this weekend. ;) – linhartr22 May 1 '15 at 17:41
2

Probably the best way would be
const uint8_t LED_PIN = 9; // may require to #include <stdint.h>
or
const byte LED_PIN = 9; // with no include necessary
const unsigned char LED_PIN = 9; // similarly
The name is in caps as per general practice in C++ (and others) to name constants. This should not use any RAM in itself, and use about 1 byte of program memory per use.
However, there might be problems when the number is higher than 127 and is sign-extended while getting promoted to larger signed integers (not entirely sure on this), although that is unlikely to happen with pin numbers.

-1

Not only will

const int ledPin = 9;

take up RAM, but in this case, will use more RAM than necessary as digitalWrite(uint8_t, uint8_t) only needs one-byte arguments, and an int is usually two bytes (compiler-dependent, but typical). Note that you can give the literal an explicit type in the #define:

#define ledPin ((int)9) 

though in a context such as a function argument where a specific type is required (because the function was properly prototyped!) it would either be implicitly cast or get an error message if the types don't match.

  • @DrivebyDownvoter, would you comment on your reasons? – JRobert Apr 30 '15 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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