Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

when would you use static and const?

Status
Not open for further replies.

electroRF

Member
Hi,
I learned about static and const keywords.

I actually knew them before but got into it more deeply.

I have 2 questions please:

1. when would you use static keyword? say for local variable and / or for global variable?

2. when would you use const? (I can't think of a situation where I'd rather use const rather than #define).

Thank you very much.
 
Last edited:
Start with this I am sure others will have something to add.


Regarding #1
Static makes a variable persistent.
Global variables are already persistent so it makes no sense to use the static modifier with a global.

If you have a value that needs to be persistent but only read or modified from one function you would make it local to that function and static.


Regarding #2
#define uses simple text substitution done by by cpp. The compiler sees a un-named constant, literal, for each instance of your #defined item. If you use "var const" the compiler and debugger see a named variable.

On the surface this seems trivial but if you #define too much stuff what the compiles sees and what you see are different enough to make debugging harder.
 
Hi 3V,
Thank you very much friend.

I wrote my comments below:

Start with this I am sure others will have something to add.


Regarding #1
Static makes a variable persistent.
Global variables are already persistent so it makes no sense to use the static modifier with a global.


If you have a value that needs to be persistent but only read or modified from one function you would make it local to that function and static.

1. you're not exactly correct - if you want a global variable not to be shared with other files (by name), then you'd want to define it as static.

2. I'm looking for an example of exactly what you described - when for example a "value needs to be persistent but only read of modified from one function?" - i'm looking for an example from programmers' "everyday life".

Regarding #2
#define uses simple text substitution done by by cpp. The compiler sees a un-named constant, literal, for each instance of your #defined item. If you use "var const" the compiler and debugger see a named variable.

On the surface this seems trivial but if you #define too much stuff what the compiles sees and what you see are different enough to make debugging harder.

3. I understand.
however say you do:
#define X 5 (instead of const int X = 5;)
if you write somehwere in your code
X = 23;
the compiler would produce an error, as you can't assign a value to the number 5.
so what's the difference?
 
Global variables are already persistent so it makes no sense to use the static modifier with a global.

Static keyword on a global variable makes the variable visible only in the file it is defined. It also changes the linkage from external to internal. This means that if some other module (file) defines a global variable with the same name, the variables do not collide. It is good practice to define global variables in a module as static.
 
Static keyword on a global variable makes the variable visible only in the file it is defined. It also changes the linkage from external to internal. This means that if some other module (file) uses a global variable with the same name, the variables do not collide. It is good practice to define global variables in a module as static.

thank you very much T.

BTW - aren't the two following sentences are the same?

a. Static keyword on a global variable makes the variable visible only in the file it is defined.

b. It also changes the linkage from external to internal.

or to be more correct- a. is a result of b.
 
thank you very much T.

BTW - aren't the two following sentences are the same?

a. Static keyword on a global variable makes the variable visible only in the file it is defined.

b. It also changes the linkage from external to internal.

or to be more correct- a. is a result of b.
Yes, kind of..
 
I had forgotten about the global aspect of static.

however say you do:
#define X 5 (instead of const int X = 5;)
if you write somehwere in your code
X = 23;
the compiler would produce an error, as you can't assign a value to the number 5.
so what's the difference?

Lets say we do one of the following
#define START_TEMP 70
x=START_TEMP;
or
int const StartTemp = 70;
x=StartTemp;

when debugging the first bit of code we see
x=70;

for the const we see
x=StartTemp;

The next guy that looks at it may not associate 70 with the starting temperature. StartTemp has symbolic meaning which clues him in.
 
Hi 3V,
Thank you very much.

Thank you too so much T.

when debugging the first bit of code we see
x=70;

for the const we see
x=StartTemp;

how come?

When you debug your code in IDE, you will still see START_TEMP, and not 70.

The compiler will see 70 instead of START_TEMP, as the pre-processor will put 70 every place START_TEMP is written, but you as a user who uses IDE in Debug Mode, will see START_TEMP.
 
Lets say we do one of the following
#define START_TEMP 70
x=START_TEMP;
or
int const StartTemp = 70;
x=StartTemp;

Another distiction that "int const" is supposed to allocate a variable somewhere. It has a size, you can create a pointer to it etc. Embedded controllers have very diverse architectures, so, in theory, it is possible for the compiler to allocate this variable somewhere where it cannot be changed at run time.

"#define" doesn't have anything physical behind it, simply a different way to write the same thing.
 
Hi 3V,...

When you debug your code in IDE, you will still see START_TEMP, and not 70.

The compiler will see 70 instead of START_TEMP, as the pre-processor will put 70 every place START_TEMP is written, but you as a user who uses IDE in Debug Mode, will see START_TEMP.
What the user sees in the debugger is up to the guy(s) doing that code. Embedded tools historically have had a small market and are not always the best. They may opt to use post cpp code as it is easier.

I am not passionate about this. It is what it is.
 
const is also used to restrict writing to variables, or to make it known that a member function is not going to modify the object instance.

e.g.
Code:
struct MyClass{
   int value;
   void setValue(const int &newValue)  // states that newValue won't (can't) be changed in this function
   {
      value = newValue;
   }
   void setValue2(int &newValue)  
   {
      value = newValue;
   }
   int getValue() const    // states that this function won't (can't) change any values in the instance of this class
   {
      return value;
   }
   int getValue2()
   {
      return value;
   }
};

The setValue() function can be called with a const int or int type parameter, whereas setValue2() cannot have a const in passed as the parameter. The getValue() function may be called on a constant reference to an instance of MyClass, whereas getValue2() may not.
 
electroRF said:
2. I'm looking for an example of exactly what you described - when for example a "value needs to be persistent but only read of modified from one function?" - i'm looking for an example from programmers' "everyday life".


I am working on a home alarm system, I ended up redesigning it, but originally I used a static local variable in the "PollSensors" function. Each sensor is assigned to a zone and the PollSensors function would read each sensor, compare its current state to its previous state and if one or more sensors in a zone had changed state then the zone status was updated. The static local variable was used to store sensor states, all other functions only cared about zones, not individual sensors so there was no reason to expose the sensor state to the rest of the program, but I needed to store the state between function calls so I could detect a change.
 
Last edited by a moderator:
I often use constants to define strings for LCD display etc. Making them constants means they are stored in ROM and not precious RAM.

Mike.
 
I suspect that behaviour might depend on the architecture, compiler and how you use the variable. On PIC there are two types of ROM (well ROM-ish), the program flash can't be accessed by the program and the data EEPROM is slow to read and can't be directly referenced, so in most cases I suspect const's would be treated like any other variable and be stored in RAM, but at least they would only be stored once. If you used #define then they would be stored in program flash multiple times.
 
Hi guys,
Thank you very much!

heydonms,
Great Example with the sensors, thanks!

heydonms, Pommie
It seems that you both says opposite thing.
Pommie, you said that the const are stored in ROM, while heydonms you said that they are stored in RAM?

but at least they would only be stored once. If you used #define then they would be stored in program flash multiple times
Why would #define be stored several times and not once?
 
I am saying they would be stored in RAM on a PIC because the alternative is too complicated to implement on that particular hardware, for too little gain and no one would bother creating a compiler to do it. If you are working on an architecture that has ROM in the same address space as RAM then Pommie's description is far more likely to be correct.

Knowing how variables will be handled just comes down to knowing the hardware you are working on.

#define's are handled by the preprocessor using a basic search and replace before the source is sent to the compiler, if you define a name for a long string, then by the time it hits the compiler all it sees is a bunch of strings. If it is very good at optimising it might figure out they are the same and only store them once, but I suspect that isn't common. Where as if you use a const (or a normal variable for that matter) the string is stored once in the program (where the variable is initialised), copied into RAM and from then on all future references to it are just pointing to an address in RAM.

EDIT:
After a bit more research it appears some compilers do store a single copy of duplicated strings, but it seems to be limited to larger OO languages (java, .Net, etc.) probably not going to happen with C on a micro.
 
Last edited:
Hi heydonms,
Thank you very much!

I appreciate your knowledge :)

I'd like to enhance my knowledge in ROM / RAM management.

for example, i didn't know the following fact that you mentioned:
Where as if you use a const (or a normal variable for that matter) the string is stored once in the program (where the variable is initialised), copied into RAM and from then on all future references to it are just pointing to an address in RAM.

Where could one read about this subject of ROM / RAM handling?

Thank you :)
 
Most of what I talk about tends to be specific to a subset of PIC chips, because that is what I mostly work on so don't take any of it as universal truth.

If you are interested in a particular family of uC then datasheets are probably as good a starting point as anything.

If you are interested in general concepts then maybe start by reading up on harvard and von neumann architectures, address spaces...and nothing else springs to mind right now...
 
Hi guys,

I'm trying to understand the PIC18F block diagram (specifically, i have PIC18F4520).

Since the PIC18F is 8-bit, i.e. the address bus and data bus are 8-bit, wouldn't you expect the Program Coutner register to be 8-bit as well?

in the Block Diagram, it appears to be 20-bit.

blocks.PNG
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top