#include<stdio.h>
struct str
{
static int a ;
int b ;
} s ;
int main()
{
static int p , k ;
printf("%d %d",sizeof(p),sizeof(s));
getchar();
return 0;
}
above code is giving errors . But if I redefine the first member of the structure to 'int' rather than 'static int' then it runs fine . Why static members are not allowed in the structure and what is its significance ?
There's simply no such feature in C language. And there's no meaningful conceptual framework for such feature in C.
You see, in C++ terms, there's only one relevant difference between a static
member variable and an ordinary global variable: the scope in which its name is declared and the corresponding naming syntax. A global variable could be called a
, while a static member of the class would be called SomeClass::a
. Besides scoped naming, there are no other differences. (I deliberately ignore other C++-specific features, like access control, since they don't exist in C and this question is really about C.)
In C language a struct type does not introduce its own scope. There's no such naming syntax as SomeStruct::a
in C language. For this reason there's simply no reason to have static members in structs. You can declare a global variable instead and achieve the same effect. Call your global variable str_a
to convey the intent to "associate" it with struct str
and just think of that variable as a pseudo-static member of struct str
.
Formally speaking, one could do it the same way in C++, i.e. completely ignore this feature of C++ language and use global functions and variables instead of static function and variables inside classes. However, by doing that one would forsake all member access control features of C++. And these features are really worth having. C language has no access control features, meaning that in C one loses [almost] nothing.
The language just doesn't allow it. There's no deeper reason other than that it's not part of the design. You can always achieve the same behaviour with a separate global variable like this:
struct str
{
int b;
} s;
int str_a;
Note that it would be something entirely different to have a non-static int a;
inside your struct, which would be a distinct subelement of every object of type struct str
.
(Note also that in C++, a language evolved from C, static class members do exist and behave exactly like the workaround I described above, only that the name of the global variable is tightly associated to the name of the class.)
A static modifier is to declare your variable in the global scope in your file and a static modifier in a function creates a variable with a persistant value limited to the scope of this functions. And you can not share the value of this integer between your instances of your struct.
This is not and cannot be supported in C ;)
Why do you want to use a static member in a struct? maybe there is (there must be) a better soluation.
You have good answers here: http://cboard.cprogramming.com/c-programming/123691-static-variable-structure.html
generally speaking you don't have any gain from declaring it static, but if you still wish to it , you may migrate to c++ or declare the whole struct as static.
No, not in C. I believe C++ can do this and it means there is one copy of a
that is shared amongst all instances of the struct str
structure.
If you want to do something similar in C, you have a few options (there may be more, I just can't think of them at the moment).
The first is to break out the common variable with something like:
int struct_str_static_a;
struct str {
int b;
} s;
That way, there is only one copy of a
shared by all instances of the structure - each instance still gets its own copy of b
.
A slight modification to that is to introduce a pointer to that common variable and initialise the pointer:
int struct_str_static_a;
struct str {
int *pA;
int b;
} s;
:
s.pA = &struct_str_static_a;
Then you can use *(s.pA)
where before you would have used s.a
. Because every instance of struct str
has its own pA
pointer that points to a single a
, that gives you a similar effect. However, it's a torturous road to follow.
The third option is to get yourself on the next ISO C working group and put this forward as a change to the language. However, that's going to require a fair bit of effort from yourself for the next ten years or so, probably not worth the effort :-)