Where should I installize variables?

So, over the summer I read the book "Sams Teach Yourself C in 21 Days" that my uncle gave me. Then after heading that I bought another "Sams Teach Youself C in 24 Hours" so, I could refine my C skills even more. But I found differences in the way they taught to code between the two books... One difference is in 'Teach Yourself C in 21 Days' I was taught to installize my varibles before the 'int main()' function, and in 'Teach Yourself C in 24 Hours' I was taught to installize my variables after the 'int main()' function. What is the correct way to do this, or the more standard way???

Comments

  • : So, over the summer I read the book "Sams Teach Yourself C in 21 Days" that my uncle gave me. Then after heading that I bought another "Sams Teach Youself C in 24 Hours" so, I could refine my C skills even more. But I found differences in the way they taught to code between the two books... One difference is in 'Teach Yourself C in 21 Days' I was taught to installize my varibles before the 'int main()' function, and in 'Teach Yourself C in 24 Hours' I was taught to installize my variables after the 'int main()' function. What is the correct way to do this, or the more standard way???
    :


    All of the above are correct. There is no one right answer to that question. Certainly they should be initialized before they are used. The difference between initializing variables outside main() and inside main() is :

    1. Variables initialized outside any function are initialized at compile and link time instead of run time.
    [code]
    int a = 100;
    int b = 50;
    int main()
    {
    // no further initialization needed
    }
    [/code]

    2. Variables initialized inside a function require additional runtime processing.
    [code]
    int main()
    {
    int a = 100;
    int b = 200;
    }
    [/code]

  • : : So, over the summer I read the book "Sams Teach Yourself C in 21 Days" that my uncle gave me. Then after heading that I bought another "Sams Teach Youself C in 24 Hours" so, I could refine my C skills even more. But I found differences in the way they taught to code between the two books... One difference is in 'Teach Yourself C in 21 Days' I was taught to installize my varibles before the 'int main()' function, and in 'Teach Yourself C in 24 Hours' I was taught to installize my variables after the 'int main()' function. What is the correct way to do this, or the more standard way???
    : :
    :
    :
    : All of the above are correct. There is no one right answer to that question. Certainly they should be initialized before they are used. The difference between initializing variables outside main() and inside main() is :
    :
    : 1. Variables initialized outside any function are initialized at compile and link time instead of run time.
    : [code]
    : int a = 100;
    : int b = 50;
    : int main()
    : {
    : // no further initialization needed
    : }
    : [/code]
    :
    : 2. Variables initialized inside a function require additional runtime processing.
    : [code]
    : int main()
    : {
    : int a = 100;
    : int b = 200;
    : }
    : [/code]
    :
    :

    You may also want to note that variables declared outside of functions can be considered global variables which dont 'dissapear' when the function goes out of scope.
  • : You may also want to note that variables declared outside of functions can be considered global variables which dont 'dissapear' when the function goes out of scope.
    :

    Globals? They are(in most cases) the chaos, the danger!! The source of many problems...
  • : : You may also want to note that variables declared outside of functions can be considered global variables which dont 'dissapear' when the function goes out of scope.
    : :
    :
    : Globals? They are(in most cases) the chaos, the danger!! The source of many problems...
    :


    ***So... Basically just installize them inside, to prevent any problems down the road...?
  • The problem with globals are not related to initialization. If you do not specifically initialize them to something else the compiler will initialize them with zeros. I believe that is in the C and C++ language specifications. There are a lot of other problems with globals, so it is best to use them sparently, if at all. Its even more important in C++.
  • : The problem with globals are not related to initialization. If you do not specifically initialize them to something else the compiler will initialize them with zeros. I believe that is in the C and C++ language specifications. There are a lot of other problems with globals, so it is best to use them sparently, if at all. Its even more important in C++.
    :

    If not initialized by you, I've had experience with the compiler initializing them with garbage values, such as a global int may be initialized to the value equal to the sizeof(int), or 0, or who knows what. To be safe, always initialize a global yourself, "int i = 0;". I use globals all the time, never with problems. Example, a thread can't access the main threads variables with any success without calling some main thread's function to return the value. But globals are available to both threads simutaneously. The rule I use is if I need a variable that needs to be evaluated by multiple functions along the path and it's not possible to pass the value along as an arguement to every function, then use a global. There's nothing wrong with it at all. I use dozens of globals throughout alot of my programs. I also think it makes cleaner, more consistent code.
  • : : The problem with globals are not related to initialization. If you do not specifically initialize them to something else the compiler will initialize them with zeros. I believe that is in the C and C++ language specifications. There are a lot of other problems with globals, so it is best to use them sparently, if at all. Its even more important in C++.
    : :
    :
    : If not initialized by you, I've had experience with the compiler initializing them with garbage values, such as a global int may be initialized to the value equal to the sizeof(int), or 0, or who knows what. To be safe, always initialize a global yourself, "int i = 0;". I use globals all the time, never with problems. Example, a thread can't access the main threads variables with any success without calling some main thread's function to return the value. But globals are available to both threads simutaneously. The rule I use is if I need a variable that needs to be evaluated by multiple functions along the path and it's not possible to pass the value along as an arguement to every function, then use a global. There's nothing wrong with it at all. I use dozens of globals throughout alot of my programs. I also think it makes cleaner, more consistent code.
    :
    [blue]Completely agree with DB1.

    Somehow, the use of global variables for the code considered like a red clothing for a bull.

    Nothing wrong with them - when used properly. In some cases
    globals even speed up the program.

    Cheers![/blue]
  • : : : The problem with globals are not related to initialization. If you do not specifically initialize them to something else the compiler will initialize them with zeros. I believe that is in the C and C++ language specifications. There are a lot of other problems with globals, so it is best to use them sparently, if at all. Its even more important in C++.
    : : :
    : :
    : : If not initialized by you, I've had experience with the compiler initializing them with garbage values, such as a global int may be initialized to the value equal to the sizeof(int), or 0, or who knows what. To be safe, always initialize a global yourself, "int i = 0;". I use globals all the time, never with problems. Example, a thread can't access the main threads variables with any success without calling some main thread's function to return the value. But globals are available to both threads simutaneously. The rule I use is if I need a variable that needs to be evaluated by multiple functions along the path and it's not possible to pass the value along as an arguement to every function, then use a global. There's nothing wrong with it at all. I use dozens of globals throughout alot of my programs. I also think it makes cleaner, more consistent code.
    : :
    : [blue]Completely agree with DB1.
    :
    : Somehow, the use of global variables for the code considered like a red clothing for a bull.
    :
    : Nothing wrong with them - when used properly. In some cases
    : globals even speed up the program.
    :
    : Cheers![/blue]
    :

    The problem with globals is they increase program complexity, i.e. it's harder to use them "properly" and easier to use the improperly (and worse subtely improperly), and most of the time they are hardly necessary or even wanted. Many of the considered better programming paradigms are partially based on the fact that globals are bad. In pure functional programming there is no global data, everything is local to a function, in object-oriented programming we localize data to objects. Localizing information of any kind is usually more scalable, maintainable, and meaningful and usually the costs, if any, in performance are negligible and more than made up by a simpler more modular design.

    To DB1: Many times globals are convenient and there are times when they are a better idea, however I have a question: for most of your code what approximately is the ratio between global data symbols and all data symbols? Why do I ask? If you use dozens of globals, but thousands of other symbols then proportionally you rarely use globals, which only illustrates the point. Of course this can bite me in the ass, as a simple program can take more globals, i.e. if you use 32 globals but only have 100 symbols in your program then the proportion is strongly in favor of globals, but that hardly represents a real-world program.

    "We can't do nothing and think someone else will make it right."
    -Kyoto Now, Bad Religion

  • : : : : The problem with globals are not related to initialization. If you do not specifically initialize them to something else the compiler will initialize them with zeros. I believe that is in the C and C++ language specifications. There are a lot of other problems with globals, so it is best to use them sparently, if at all. Its even more important in C++.
    : : : :
    : : :
    : : : If not initialized by you, I've had experience with the compiler initializing them with garbage values, such as a global int may be initialized to the value equal to the sizeof(int), or 0, or who knows what. To be safe, always initialize a global yourself, "int i = 0;". I use globals all the time, never with problems. Example, a thread can't access the main threads variables with any success without calling some main thread's function to return the value. But globals are available to both threads simutaneously. The rule I use is if I need a variable that needs to be evaluated by multiple functions along the path and it's not possible to pass the value along as an arguement to every function, then use a global. There's nothing wrong with it at all. I use dozens of globals throughout alot of my programs. I also think it makes cleaner, more consistent code.
    : : :
    : : [blue]Completely agree with DB1.
    : :
    : : Somehow, the use of global variables for the code considered like a red clothing for a bull.
    : :
    : : Nothing wrong with them - when used properly. In some cases
    : : globals even speed up the program.
    : :
    : : Cheers![/blue]
    : :
    :
    : The problem with globals is they increase program complexity, i.e. it's harder to use them "properly" and easier to use the improperly (and worse subtely improperly), and most of the time they are hardly necessary or even wanted. Many of the considered better programming paradigms are partially based on the fact that globals are bad. In pure functional programming there is no global data, everything is local to a function, in object-oriented programming we localize data to objects. Localizing information of any kind is usually more scalable, maintainable, and meaningful and usually the costs, if any, in performance are negligible and more than made up by a simpler more modular design.
    :
    : To DB1: Many times globals are convenient and there are times when they are a better idea, however I have a question: for most of your code what approximately is the ratio between global data symbols and all data symbols? Why do I ask? If you use dozens of globals, but thousands of other symbols then proportionally you rarely use globals, which only illustrates the point. Of course this can bite me in the ass, as a simple program can take more globals, i.e. if you use 32 globals but only have 100 symbols in your program then the proportion is strongly in favor of globals, but that hardly represents a real-world program.
    :
    : "We can't do nothing and think someone else will make it right."
    : -Kyoto Now, Bad Religion
    :
    :
    It really depends on the type of program i'm writing. If it's an app that deals with directories, files, registry entries etc.. the global vs standard vars ratio can be quite high in order to save overhead in multiple directory searches to retrieve files & paths and other various tasks. Otherwise global use is normally quite low. The point I was trying to make is that globals are completely acceptable and in some cases more desirable, and their use in no way should be discouraged.
  • : So, over the summer I read the book "Sams Teach Yourself C in 21 Days" that my uncle gave me. Then after heading that I bought another "Sams Teach Youself C in 24 Hours" so, I could refine my C skills even more. But I found differences in the way they taught to code between the two books... One difference is in 'Teach Yourself C in 21 Days' I was taught to installize my varibles before the 'int main()' function, and in 'Teach Yourself C in 24 Hours' I was taught to installize my variables after the 'int main()' function. What is the correct way to do this, or the more standard way???
    :

    Hi,

    There is a subtle difference but I would declare the variables inside. This is the standard way. For example,

    [code]
    #include

    int main()
    {
    /* Declaring the variable */
    int variable;

    return 0;
    }
    [/code]

    Hope this helps,
  • : : The problem with globals are not related to initialization. If you do not specifically initialize them to something else the compiler will initialize them with zeros. I believe that is in the C and C++ language specifications. There are a lot of other problems with globals, so it is best to use them sparently, if at all. Its even more important in C++.
    : :
    :
    : If not initialized by you, I've had experience with the compiler initializing them with garbage values, such as a global int may be initialized to the value equal to the sizeof(int), or 0, or who knows what. To be safe, always initialize a global yourself, "int i = 0;". I use globals all the time, never with problems. Example, a thread can't access the main threads variables with any success without calling some main thread's function to return the value. But globals are available to both threads simutaneously. The rule I use is if I need a variable that needs to be evaluated by multiple functions along the path and it's not possible to pass the value along as an arguement to every function, then use a global. There's nothing wrong with it at all. I use dozens of globals throughout alot of my programs. I also think it makes cleaner, more consistent code.
    :

    ---------------------------------------------------

    *** WORD -.a.e.
  • its best (performance and style wise) to initialize variables right when you define them (if the value is already known), like
    [code]
    int a = 3;
    //instead of
    int a;
    a = 3;
    [/code]

    and please do yourself a favor and dont get used to the use of global variables. they are simply evil. only use them if you dont see another way (not only because it seems to be easier). they kill maintainability and reusability, they destroy modularity, they create unnecessary dependencies.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories