I've faced three separate situations in C lately that I would assistance on:
My C code has a global variable:
int ref_buf; //declared in a header file
In a function definition I use the same name as a parameter:
void fun(int ref_buf, param2, param3)
{
}
Will it overwrite the originally defined global variable and will it cause bugs?
Can I declare a static variable in a C data structure like so?:
struct my
{
int a;
static int b;
};
Does it work? Is there any specific situation where one would need it?
Can I initialize a individual structure variable as follows:
struct my
{
int a;
int b = 4;
};
Question 1
All references to ref_buf in that function will bind to the parameter and not the global variable.
Question 2
This is not legal in C but is legal in C++. The keyword static in C can only be used on file scope variables or on locals.
Question 3
No this is not legal in C (or C++). You will need to create a factory method to handle this.
my create_my() {
my m;
m.b = 4;
return m;
}
On Q3: GCC allows you to initialize a struct like this (as required by the C99 standard):
struct
{
int a;
int b;
} my = { .b = 4 };
GCC doc on designated initializers
1a) The local and global variables are separate entities, and so the local one won't overwrite the global. However, the global one won't be accessible inside the function (see also notes below).
1b) It not actually incorrect, but it is guaranteed to cause confusion, and confusion causes bugs, so it's best to use different names for each.
2) No, that's not legal C. You can however make the whole struct static.
3) No. You do it like this:
struct my
{
int a;
int b;
} = {0, 4};
Note 1: Variables should be declared in .c files, not .h files. If you need to make a variable accessible in multiple files, put an extern declaration in the header file.
Note 2: Avoid global variables if at all possible.
Question 1:
I think the variable declared in the local scope takes precidence, it shouldn't overwrite it but in the scope that the variable is declared it will be used instead.
That is assuming that it compiles.
On Q1:
Do not declare variables in a header file. If you include that header file in two source files and compile the source files together, you've got problems. Maybe your linker will get you out of them, maybe not.
If you really need global variables, and this happens a lot less than typical beginners think, put something like extern int ref_buf; in the header file, and int ref_buf; in a source file. That means there is one ref_buf, and all other source files will be able to find it.
The function parameter is essentially a new variable with the same name, and all references in the function will be to it. You will not be able to access the global variable from within that function. The function creates an inner scope, and variables declared in an inner scope are different from those in an outer one. This is potentially confusing, and makes it easy to create bugs, so having variables of the same name and different scopes is generally discouraged. (Variables of the same name in different struct definitions are usually not confusing, since you have to specify what struct contains the variable.)
The compiler will compile the function, but a good compiler will issue a warning message. If it refuses to compile because of one variable shadowing another of the same name, it isn't a real C compiler.
1) Local variables always take precedence e.g.
int ref = 10;
void fun(int ref)
{
printf("\n%d\n", ref);
}
int main()
{
fun(252);
return 0;
}
shows: 252
Qs 2 and 3 won't work in C.
Yes, it will technically overwrite, but a good compiler will warn you about this situation, and you will have "warnings = errors" on when you compile, so this won't actually compile.
Not needed, since the "my" struct is already declared as static, and it is therefore declared for the entire struct. This allocates the memory for the entire struct, so there is no need to say "take part of the struct which is already static and make it static".
No, not in the definition, but you can when you create an "instance", something like:
struct my MY =
{
{0, 4}
};
Related
#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 :-)
I am reading the book "Programming in C" and found in Chapter 10 an example like this:
#include <stdio.h>
void test (int *int_pointer)
{
*int_pointer = 100;
}
int main (void)
{
void test (int *int_pointer);
int i = 50, *p = &i;
printf ("Before the call to test i = %i\n", i);
test (p);
printf ("After the call to test i = %i\n", i);
return 0;
}
I understand the example, but I don't understand the line void test (int *int_pointer); inside of main. Why do I define the signature of test again? Is that idiomatic C?
It's definitely not idiomatic C, despite being fully valid (multiple declarations are okay, multiple definitions are not). It's unnecessary, so the code will still work perfectly without it.
If at all, perhaps the author meant to do
void test (int *int_pointer);
int main (void) {
...
}
in case the function definition was put after main ().
void test (int *int_pointer); is just a declaration (or prototype) of function test. No need of this declaration in main because you already have function definition before main.
If the definition of test were after main then it would be worth of putting its declaration there to let the compiler know about the return type, number of arguments and arguments types of test before calling it.
It's not idomatic C, but still valid.
The line is a declaration of the function test, not definition. A function can't be defined multiple times, but it's valid to have multiple declarations.
It is perfectly idiomatic C, and it actually has a (limited) practical use - although not one that is demonstrated by this example.
When you declare a function or other name at the usual global level, it is brought into scope for all function bodies in the code following the declaration. A declaration cannot be removed from a scope once it has been introduced. The function is permanently visible to the rest of the translation unit.
When you declare a function or other name within a braced block, the scope of the declaration is limited to that block. Declaring a function within the scope of another function will limit its visibility, and not pollute the global namespace or make it visible to any other functions defined in the same translation unit.
This is meaningless in the case of the example, because the definition of test also brings it into scope for all following bodies - but if test were defined in another translation unit, or even if it were defined only at the very bottom of this TU, hiding the declaration inside main would protect any other functions defined afterwards from being able to see its name in their scope.
In practical terms this is of limited use - normally if you don't want a function to be visible, you put it in another translation unit (and preferably make it static) - but you can probably contrive a situation where you might want to use this ability for constructing a module-loading system that doesn't export the original declarations of its components, or something like that (and the fact that this doesn't rely on static/separate object files might potentially have some relevance to embedded/non-hosted target environments where the linking step might not work as it does on PC, allowing you to achieve a measure of namespace protection in a purely-#include-based build system).
Example:
struct module {
void * (* alloc)(size_t);
void (* dealloc)(void *);
} loaded_module;
int main(void) {
if (USE_GC) { // dynamically choose the allocator system
void * private_malloc_gc(size_t);
void private_free_noop(void *);
loaded_module = (struct module){ private_malloc_gc, private_free_noop };
} else {
void * private_malloc(size_t);
void private_free(void *);
loaded_module = (struct module){ private_malloc, private_free };
}
do_stuff();
//...
}
// cannot accidentally bypass the module and manually use the wrong dealloc
void do_stuff(void) {
int * nums = module.alloc(sizeof(int) * 32)
//...
module.dealloc(nums);
}
#include "allocator_implementations.c"
It's not idiomatic; you typically see it in code that has problems getting their header files in order.
Any function is either used in one file only, or it is used in multiple files. If it is only used in its own file, it should be static. If it is used in multiple files, its declaration should be in a header file, and anyone using it should include the header file.
What you see here is very bad style (the function should either be static, or the declaration should be taken from a header style), and also quite pointless because the compiler can see the declaration already. Since the function is in the same file, it's not dangerous; if the declaration and function don't match the compiler will tell you. I have often seen this kind of thing when the function was in a different file; that is dangerous. If someone changes the function, the program is likely to crash or misbehave.
I am reading the book "Programming in C" and found in Chapter 10 an example like this:
#include <stdio.h>
void test (int *int_pointer)
{
*int_pointer = 100;
}
int main (void)
{
void test (int *int_pointer);
int i = 50, *p = &i;
printf ("Before the call to test i = %i\n", i);
test (p);
printf ("After the call to test i = %i\n", i);
return 0;
}
I understand the example, but I don't understand the line void test (int *int_pointer); inside of main. Why do I define the signature of test again? Is that idiomatic C?
It's definitely not idiomatic C, despite being fully valid (multiple declarations are okay, multiple definitions are not). It's unnecessary, so the code will still work perfectly without it.
If at all, perhaps the author meant to do
void test (int *int_pointer);
int main (void) {
...
}
in case the function definition was put after main ().
void test (int *int_pointer); is just a declaration (or prototype) of function test. No need of this declaration in main because you already have function definition before main.
If the definition of test were after main then it would be worth of putting its declaration there to let the compiler know about the return type, number of arguments and arguments types of test before calling it.
It's not idomatic C, but still valid.
The line is a declaration of the function test, not definition. A function can't be defined multiple times, but it's valid to have multiple declarations.
It is perfectly idiomatic C, and it actually has a (limited) practical use - although not one that is demonstrated by this example.
When you declare a function or other name at the usual global level, it is brought into scope for all function bodies in the code following the declaration. A declaration cannot be removed from a scope once it has been introduced. The function is permanently visible to the rest of the translation unit.
When you declare a function or other name within a braced block, the scope of the declaration is limited to that block. Declaring a function within the scope of another function will limit its visibility, and not pollute the global namespace or make it visible to any other functions defined in the same translation unit.
This is meaningless in the case of the example, because the definition of test also brings it into scope for all following bodies - but if test were defined in another translation unit, or even if it were defined only at the very bottom of this TU, hiding the declaration inside main would protect any other functions defined afterwards from being able to see its name in their scope.
In practical terms this is of limited use - normally if you don't want a function to be visible, you put it in another translation unit (and preferably make it static) - but you can probably contrive a situation where you might want to use this ability for constructing a module-loading system that doesn't export the original declarations of its components, or something like that (and the fact that this doesn't rely on static/separate object files might potentially have some relevance to embedded/non-hosted target environments where the linking step might not work as it does on PC, allowing you to achieve a measure of namespace protection in a purely-#include-based build system).
Example:
struct module {
void * (* alloc)(size_t);
void (* dealloc)(void *);
} loaded_module;
int main(void) {
if (USE_GC) { // dynamically choose the allocator system
void * private_malloc_gc(size_t);
void private_free_noop(void *);
loaded_module = (struct module){ private_malloc_gc, private_free_noop };
} else {
void * private_malloc(size_t);
void private_free(void *);
loaded_module = (struct module){ private_malloc, private_free };
}
do_stuff();
//...
}
// cannot accidentally bypass the module and manually use the wrong dealloc
void do_stuff(void) {
int * nums = module.alloc(sizeof(int) * 32)
//...
module.dealloc(nums);
}
#include "allocator_implementations.c"
It's not idiomatic; you typically see it in code that has problems getting their header files in order.
Any function is either used in one file only, or it is used in multiple files. If it is only used in its own file, it should be static. If it is used in multiple files, its declaration should be in a header file, and anyone using it should include the header file.
What you see here is very bad style (the function should either be static, or the declaration should be taken from a header style), and also quite pointless because the compiler can see the declaration already. Since the function is in the same file, it's not dangerous; if the declaration and function don't match the compiler will tell you. I have often seen this kind of thing when the function was in a different file; that is dangerous. If someone changes the function, the program is likely to crash or misbehave.
Here is an example code, struct A is declared and then it's instance "instanceOfA" is defined inside main, so it become local variable and to access it in other functions I should pass it as an argument. On the other hand struct B is declared and it's instance defined as global variable that allows me to use "instanceOfB" anywhere I need it, directly instead of passing it around as an argument. The only thing I should worry about now is that some function may overwrite "instanceOfA" identifier right? since it's variables (a,b,c) already in it's own "namespace". So is it a bad practice to define struct object as global variable? What would you do?
Sorry for my poor English.
struct A {
int a,b,c;
};
struct B {
int a,b,c;
} instanceOfB;
int main(void) {
struct A instanceOfA;
instanceOfA.a = 5;
instanceOfB.a = 10;
}
I'm not sure what is the question about exactly, but here are some thoughts.
instanceOfB is a global variable, right? So, it is an evil that should be avoided if not strictly necessary.
On the contrary, struct A instanceOfA; inside function body looks fine for me, though we usually move types from struct namespace to global namespace by using typedef struct idiom to reduce typing.
Yes, indeed, it is very bad practice to define anything as a global variable, not just a struct.
Yes, you will need to be passing it as a parameter. That's actually good, not bad.
It means that every single individual piece of code (function) in your program will only be able to modify what it is being given to modify, and not whatever it pleases.
Is it fine to declare a global variable as auto.
for example
auto int i;
static int j;
int main()
{
...
return 0;
}
Why haven't you tried compiling the code snippet in your question? If you had, you would know by now that it gives a compiler error. In gcc:
foo.c:3: error: file-scope declaration of 'x' specifies 'auto'
So I guess the answer tyo your question is "no, it's not fine".
The meaning of 'auto' in C is simply a variable that is a local variable.
So it is totally contradictory to say you would like to declare a global variable as a local variable.
I think you are talking about having a localised global. If you would like to declare a variable that is local to the .c file you are working in, and you don't want it to be accessible outside the c file, but you would like for it to be accessible by all functions in that file, you should declare it as a static variable, like you have done for the variable j.
Therefore you would have something like the following in example.c:
static int i; //localised global within the file example.c
static int j; //not accessible outside the .c file, but accessible by all functions within this file
int main()
{
//do something with i or j here.
i = 0 ;
j = 1 ;
}
void checkFunction()
{
//you can also access j here.
j = j+ 5;
}
I guess I should add that there are multiple ways you to use the keyword static for a variable.
The one that you might be familiar with is:
1) Declaring a variable static within a function - this ensures the variable retains its value between
function invocations.
The second one ...
2) Declaring a variable as static within a module (or a .c file) - this is what I have described
above. This ensures a variable is localised within that module or .c file, but it is global so that
it can be used by any of the functions defined in that particular file. Hence the name localised
global.
However, it will not be accessible outside that .c file.
Based on this explanation of auto:
http://msdn.microsoft.com/en-us/library/6k3ybftz%28VS.80%29.aspx
It says that auto variables are scope-limited, and their address is not constant. Since globals have neither of these properties, it wouldn't make sense for a global to be auto.
No, it is not possible. The reason is that global variables are in a specific data segment (along with static variables declared inside the functions) initialized to zero all at once before main() is called.