Not Keil specific; one for the 'C' experts:
Why would one put 'static' variables definitions in a header?
eg, in a header file:
/* * TCO count to temperature conversion table. */ static erTcoTableStruct tcoTableOPUS1[] = { /*{TCO,Temp,} */ {1,-99}, {4,-45}, {5,-40}, {8,-35}, {11,-30}, {16,-25}, {22,-20}, {29,-15}, {37,-10}, {48,-5}, {61,0}, {78,5}, {99,10}, {124,15}, {153,20}, {188,25}, {227,30}, {270,35}, {315,40}, {365,45}, {420,50}, {481,55}, {549,60}, {625,65}, {710,70}, {805,75}, {910,80}, {1010,85}, {1060,88} };
AIUI, the whole point of so-called "header" files in 'C' is to share stuff between source files;
But the whole point of the 'static' keyword (at file scope) in 'C' is to make stuff private so that it is not visible to other modules - ie, not shared.
So I can't see why one would want to have 'static' definitions in a header?!
My question was, what could be the point in having static definitions in a header file (irrespective of how you manage your header files); in other words, what could be the point in having multiple identically-named and identically-typed but distinct objects in the files of a project?
I congratulate you for your persistence!
The only halfway sensible reason I can come up with (which I think someone else already suggested) is to allow the instance of the struct local to each source file to modify its local instance at runtime. I'm sure someone, somewhere will have managed to find a reason to do this.
Regarding some of the other stuff in this thread:
For the confused: From the compiler's perspective include files don't exist, so special handling is not an option.
For the deluded: The convention in 'C' programming is that header files do not include any code that allocates storage. Everyone goes through the "oh but I've got this great way of using header files that's much better/safer/controlled than the usual way" during their learning curve. Fortunately most of them eventually realise that the conventional approach is the best one.
When you join a company or a project you adopt the existing conventions, even though those almost certainly aren't the best. Why would you join a community of (presumably) hundreds of thousands of 'C' programmers than decide not to follow convention?
I look forward to the responses...
Thanks!
"The only halfway sensible reason I can come up with (which I think someone else already suggested) is to allow the instance of the struct local to each source file to modify its local instance at runtime."
Yes - Mike Kleshov suggested it.
Anyone (else) got any other ideas?