CODEWITHSUNDEEP
c++local-variables
Jeffrey Malone
Jeffrey Malone

Reputation: 83

Local Variables Being Passed ( C++)

I have encountered a problem in my learning of C++, where a local variable in a function is being passed to the local variable with the same name in another function, both of these functions run in main().

When this is run,

#include <iostream>
using namespace std;

void next();
void again();

int main()
{
    int a = 2;
    cout << a << endl;
    next();
    again();
    return 0;
}

void next()
{
    int a = 5;
    cout << a << endl;
}

void again()
{
    int a;
    cout << a << endl;
}

it outputs:

2
5
5

I expected that again() would say null or 0 since 'a' is declared again there, and yet it seems to use the value that 'a' was assigned in next().

Why does next() pass the value of local variable 'a' to again() if 'a' is declared another time in again()?

Upvotes: 8

Views: 137

Answers (3)

Cheers and hth. - Alf
Cheers and hth. - Alf

Reputation: 145457

An uninitialized non-static local variable of *built-in type (phew! that was a mouthful) has an indeterminate value. Except for the char types, using that value yields formally Undefined Behavior, a.k.a. UB. Anything can happen, including the behavior that you see.

Apparently with your compiler and options, the stack area that was used for a in the call of next, was not used for something else until the call of again, where it was reused for the a in again, now with the same value as before.

But you cannot rely on that. With UB anything, or nothing, can happen.

* Or more generally of POD type, Plain Old Data. The standard's specification of this is somewhat complicated. In C++11 it starts with §8.5/11, “If no initializer is specified for an object, the object is default-initialized; if no initialization is performed, an object with automatic or dynamic storage duration has indeterminate value.”. Where “automatic … storage duration” includes the case of local non-static variable. And where the “no initialization” can occur in two ways via §8.5/6 that defines default initialization, namely either via a do-nothing default constructor, or via the object not being of class or array type.

Upvotes: 5

mock_blatt
mock_blatt

Reputation: 975

http://en.cppreference.com/w/cpp/language/ub

You're correct, an uninitialized variable is a no-no. However, you are allowed to declare a variable and not initialize it until later. Memory is set aside to hold the integer, but what value happens to be in that memory until you do so can be anything at all. Some compilers will auto-initialize variables to junk values (to help you catch bugs), some will auto-initialize to default values, and some do nothing at all. C++ itself promises nothing, hence it's undefined behavior. In your case, with your simple program, it's easy enough to imagine how the compiler created assembly code that reused that exact same piece of memory without altering it. However, that's blind luck, and even in your simple program isn't guaranteed to happen. These types of bugs can actually be fairly insidious, so make it a rule: Be vigilant about uninitialized variables.

Upvotes: 7

David Hoelzer
David Hoelzer

Reputation: 16379

This is completely coincidental and undefined behavior.

What's happened is that you have two functions called immediately after one another. Both will have more or less identical function prologs and both reserve a variable of exactly the same size on the stack.

Since there are no other variables in play and the stack is not modified between the calls, you just happen to end up with the local variable in the second function "landing" in the same place as the previous function's local variable.

Clearly, this is not good to rely upon. In fact, it's a perfect example of why you should always initialize variables!

Upvotes: 1

Related Questions