Curious about pin declare...

I agree about making pin numbers const but a const int takes 2 bytes just like an int, which was the point of the original question.

kokpat:
Why people always using int for declare pin but not byte ?

Because they're ignorant/careless.

Using plain 'int' also makes the compiler generate slower code because it thinks it's variable. Always use 'const'.

Even better, use an enum, that way the compiler knows even more about how the value will be used (ie. in constant expressions) and you're covered if Atmel makes a chip with more than 255 pins.

UKHeliBob:
I agree about making pin numbers const but a const int takes 2 bytes just like an int, which was the point of the original question.

If you declare it 'const' the compiler won't put it in RAM (in theory).

Is there something wrong with #define vs. const? Why waste the storage space?

afremont:
Is there something wrong with #define vs. const?

const carries type information and never interferes with parsing.

Why waste the storage space?

Why are you concerned about the compiler's storage space?

UKHeliBob:
I agree about making pin numbers const but a const int takes 2 bytes just like an int, which was the point of the original question.

Two bytes of which storage? Flash? SRAM? Both?

fungus:
Even better, use an enum, that way the compiler knows even more about how the value will be used (ie. in constant expressions) and you're covered if Atmel makes a chip with more than 255 pins.

enum elements (values) are a good idea but, regardless of the number of elements, the type is always 16 bits.

I mean RAM. #define takes no space in RAM, int does. I don't see the benefit to setting aside 16 bits of RAM to hold the number of a pin and declaring it fixed in value. Carrying type information by being locked to a single fixed representation at run-time invites hidden promotion of the underlying value which is wasted run-time effort, #define should prevent that and let the compiler figure out the best representation for each reference to the value.

I'm not concerned at all about the compiler's work space, just my own.

Moderator edit: over-quote trimmed.

I always use byte for assigning pin numbers.
Some say not using
const byte pinX = 4;
could let the sketch accidentally change pinX by accident, I've never had such careless code where that happened.

I had some code with an array pointing to an array kind of thing where #define would not work correctly, but const byte did.

afremont:
I mean RAM. #define takes no space in RAM, int does.

And const int?

Carrying type information by being locked to a single fixed representation at run-time invites hidden promotion...

From int to what?

...#define should prevent that and let the compiler figure out the best representation for each reference to the value.

Why do you believe the compiler does not do the same with const int?

A const int is still just an int. While the compiler "might" optimize away the storage space requirement in RAM or ROM, it has absolutely no obligation to do so. The compiler is free to completely ignore the qualifier. Why depend upon something that might not even happen?

By forcing a defined type, you force the (non optimizing) compiler to promote the type here and there when it is used. People do it all the time by assigning an LED pin to an int when the real type is uint8_t. Since #define constants are basically typeless, the compiler is free to plug it in anyway it sees fit depending upon the context of the reference.

The answer to your third question is contained within the first answer. const is just a qualifier, the compiler doesn't have to do anything special just because it's there. Even attempting to change a const is implementation defined so there's not even a guarantee on how that is handled.

So your entire argument is based on a hypothetical C++ compiler that may or may not exist. Got it.

Given where we are, I will focus my attention on the compiler used to generate code for Arduinos.

Actually, my entire argument is based upon the ANSI standard definition. Given this is the forum to discuss other microcontrollers and not just the microcosm of Arduino, I think I'll stick with standard C and not what some particular compiler may or may not do with optimizations.

afremont:
Actually, my entire argument is based upon the ANSI standard definition.

Which defines a hypothetical compiler. I'm glad we agree.

Given this is the forum to discuss other microcontrollers and not just the microcosm of Arduino, I think I'll stick with standard C and not what some particular compiler may or may not do with optimizations.

So @kokpat posts his question in the wrong section and you feel compelled to start a discussion of standard C++? If that's really how you want to spend your time you are certainly welcome to have at it. I have better things to do...

Look, I didn't hijack this thread. I was only trying to add to the discussion by asking a simple question about #define vs const. You called me out specifically and I tried to answer your questions, condescending as they were. And now, because you didn't like my answers, instead of presenting a technical argument you chose to be rude about it and accuse me of being a thread jacker. Why??? I haven't done anything with any intention of insulting you. I only disagreed with you on some things technically. If you have a technical argument, bring it on I'm all in for it. No need to be insulting.

Of course the OP's question is legitimate, no need to put words into my mouth either.

...by asking a simple question...

Why waste the storage space?

A question that implies the GCC compiler does not optimize const declarations. That is not a "simple question".

...I tried to answer your questions...

Your responses are based on a hypothetical compiler. Perfect answers on a C++ standards forum. Or, in a response to a question about portability. The compiler in question is not hypothetical, this is not a standards forum, and the question was not about portability.

I haven't done anything with any intention of insulting you.

I do not feel insulted. Thank you for your concern.

No need to be insulting.

Even though I fail to understand why you feel insulted it makes no difference. I apologize for insulting you.

If you have a technical argument...

I have already stated my position. I will not engage in any argument about a hypothetical compiler. You are free to do as you please.

...bring it on I'm all in for it

"Bring it on"? No thanks.

afremont:
Actually, my entire argument is based upon the ANSI standard definition. Given this is the forum to discuss other microcontrollers and not just the microcosm of Arduino, I think I'll stick with standard C and not what some particular compiler may or may not do with optimizations.

If you want to stick with standard C, don't use the Arduino IDE. The IDE uses a C++ compiler, not C, and C++ has different semantics from C. One of the many differences between C and C++ is how file-level declarations such as "const int pin = 5;" are treated.

Ok then on the apology, thank you. :slight_smile: <--- I still think that thing looks silly, but whatever. Anyhow, ANSI C isn't something hypothetical, it's what all workable compilers are based upon. If GCC optimizes const away then that's cool, but I'm sure it would afford the same luxury to the repetitive occurrences of constant type values that were stuffed in by the preprocessor thru the use of #define. I can see the benefit of securing the type, especially in the minds of native C++ coders that tend to worry about such things. But I also appreciate the efficiency of letting the compiler pick the type on an as needed basis.

This brings us to the OP's original question. I think the answer is more a matter of monkey see monkey do with the int LEDPin thing. It's certainly not the most efficient way and it's even the wrong basic type to supply as arguments to the functions. But, it is what you will see throughout the examples.

I thought it was simple enough, I just wanted to know why the local allegiance to const over #define. It seemed to be perfectly appropriate to the course of the conversation at that point. At least I thought so.

The "bring it on" thing is about debate, not a duel. I like to argue about technical matters, it's how I learn. I am also willing to admit I'm wrong when there is a technical backing to the counter-claim. I'm not a big fan of "because I said so", or "that's the way it is here" etc. I like to see real proof and hear real logical reasoning behind an argument. When I post, I expect to be questioned if I make a technical error. I don't expect to be admonished for something I didn't do.

I apologize to the OP for this diversion. I like to try and help, but sometimes I guess I rub some folks the wrong way.

dc42:

afremont:
Actually, my entire argument is based upon the ANSI standard definition. Given this is the forum to discuss other microcontrollers and not just the microcosm of Arduino, I think I'll stick with standard C and not what some particular compiler may or may not do with optimizations.

If you want to stick with standard C, don't use the Arduino IDE. The IDE uses a C++ compiler, not C, and C++ has different semantics from C. One of the many differences between C and C++ is how file-level declarations such as "const int pin = 5;" are treated.

Ok, so it's really a fine distinction between C and C++ definitions of const. I see that they are a little differently treated by the C++ compiler as "true constants" whereas in C, they aren't so-called true constants. The only similar "true constants" in C are enums. So in a C world, the correct answer is use a #define, but in a C++ world const gives some benefit without using storage. Ok, I can cope with that. Thanks for getting me pointed in the right direction.