include<conio.h>

include<stdio.h>

include<stdlib.h>

include<math.h>

int k,i=0,m=0,flag=0;
int coef[10]={0};
float x1=0,x2=0,t=0;
float fx1=0,fdx1=0;
what is the benefits if the variables are defined outside of the function ,just after #include
thanks!!

Edited 3 Years Ago by JorgeM: Move to correct forum.

They are called Global Variables, your textbook probably discusses them. Most programmers today frown on using global variables because they can cause a lot of confusion and debugging problems. Benefits: not many.

thanks.so it means that i can use these functions within main and other user defined function without declareing them??

You don't want variables up above main() (Global), generally speaking. They are TROUBLE!

Prototype your functions above main() - YES! Same with structs. That way, any function can easily create a local struct, for temporary work.

Passing your variables to functions, ONLY if they need them, and then pass them the address to those variables you pass, ONLY if they need to alter them, is a great way to encapsulate what is going on, inside each function.

That makes bug killing later on, a LOT easier.

doesn't it reduces workload?? as we dont need to declare variables every time when we are supposed to work with user defined functions.

i mean when programme goes outside the main function???

No, it saves time and work, because those global variables are the cause of a great deal of bugs in the program, usually because global variables get "covered over" by local function variables with the same name - which happens more than you'd think it should, believe me.

In C, the ideal is to have smallish size functions, that do just one thing, clearly and efficiently. We can't always do that, but that's the ideal, and it makes trouble shooting a bug in the code, MUCH easier.

Years ago (1990s) I took over a large MS-DOS program from another programmer which had about 40 *.c files. Each of the files declared global variables that were used in many of the other files. IMO it was a horrible mess -- took me weeks to figure it all out. Eventually I consolidated all those globals into a single *.c file named Globals.c. By doing that I discovered several variables declared in more than one *.c file, which was causing problems.

if it causes so many problems and creats errors then for what purpose it was introduced in c ???

Because C wasn't designed to protect stupid people from themselves, it was designed to give smart people a lot of power and flexibility. A potentially dangerous feature can still be used to great effect when used correctly. The unfortunate truth though is that such features are often not used correctly. ;)

Edited 3 Years Ago by deceptikon

what is the definition of 'correct use' here.what type of mistakes can happen!
how can i be sure that i am not doing it correctly??

what is the definition of 'correct use' here.

Use that doesn't encourage any of the pitfalls. Global variables are very case specific, and in our day and age of multithreading they're becoming less and less usable. "Correct" use is really a matter of knowing the potential risks and writing code to limit them as much as possible.

what type of mistakes can happen!

If everyone can see and modify a variable, everyone can break it. If code that relies on a global variable doesn't treat it as potentially volatile, that's a risk of data corruption right there.

Another risk stemming from the same source is if you do encounter a bug involving the global variable, you have to treat the entire source base as suspect in causing the bug. When your code is a bunch of small black boxes communicating through well defined interfaces, bugs are much easier to trace.

how can i be sure that i am not doing it correctly??

That's where guidelines and best practice come in. If there's any doubt, follow the guidelines and you'll limit risk naturally. The guideline for global variables is: "avoid global variables". ;)

thanks.though as a new learner i thought it would be helpful,but as you guys are suggesting not to use it,i will try to avoid it next time.

This article has been dead for over six months. Start a new discussion instead.