-1

I compiled the following code using g++

#include <iostream>

int main()
{
    double res;
    std::cout << res << std::endl; 
    return 0;
}

That gave the following result

g++ foo.c
./a.out
0

But after a small change

#include <iostream>

int main()
{
    std::string input;
    double res;
    std::cout << res << std::endl; 
    return 0;
}

It became

g++ foo.c
./a.out
2.0734e-317

Why are the results different and why the number 2.0734e-317?

Dante
  • 611
  • 1
  • 7
  • 21
  • 1
    Using uninitialized variable is undefined behavior. There are many duplicates of this, but they are relatively hard to find. – Sergey Kalinichenko Nov 18 '15 at 17:08
  • I find it extremely difficult to believe that your book does not teach you to initialise your variables and explain to you why that's important. – Lightness Races in Orbit Nov 18 '15 at 17:09
  • 2
    I'm voting to close this question as off-topic because explaining the results of undefined behaviour is actually useless an unanswerable. – πάντα ῥεῖ Nov 18 '15 at 17:10
  • OTOH it's a well-formatted question with an excellent MCVE, which might serve as a pretty good canonical dupe... – Lightness Races in Orbit Nov 18 '15 at 17:10
  • @πάνταῥεῖ i actually disagree. Explaining results of undefined behaviour might be a useful excercise which allows one insights into how compilers actually operate, what kind of code is generated and why a certain rule is in place. – SergeyA Nov 18 '15 at 17:12
  • @SergeyA _"Explaining results of undefined behaviour ..."_ How can we actually explain the unpredictable? – πάντα ῥεῖ Nov 18 '15 at 17:14
  • 1
    @πάνταῥεῖ, compilers are determenistic state machines, and they produce the same code given the same input. Memory layout of a process is also determenistic. In this particular case, it is rather easy to explain results OP is seeing. – SergeyA Nov 18 '15 at 17:16
  • @SergeyA Though results might be totally different for another compiler Implementation. – πάντα ῥεῖ Nov 18 '15 at 17:17
  • @πάνταῥεῖ of course. But in any given implementation they are likely to be the same, and I believe, it is worth understanding them. Also, in this particular case, I would assume the results would be the same in most widely-used implementations. – SergeyA Nov 18 '15 at 17:19
  • @SergeyA Well, I've hammer reopened the question now, let's see if we can use it as a canonical now in future (still have my doubts). – πάντα ῥεῖ Nov 18 '15 at 17:23
  • @πάνταῥεῖ That's not _always_ a bad thing. In the general case yes we avoid rationalising about UB at all because, at the level of the abstraction that C++ provides, it's by definition pointless. But we live in a physical reality and program physical machines and, sometimes, you want to know what's really going on. For an issue like this, at least, you can even give a general idea of the sort of symptoms you're likely to see and _why_. That is not inherently without value. – Lightness Races in Orbit Nov 18 '15 at 23:06

3 Answers3

2

Your code invokes undefined behaviour. Since automatic variables of built-in types are not deafult-initialized unless specifically aksed, value for variable res is undefined in your code. It can be anything.

Why you have different value their based on different code structure is understandable - since no one is setting the value for the variable, you are left with whatever is left in the stack memory after previous calls. Pure random.

In particular, in the former example, the stack memory is not used at all before you declare your res variable. As a result, you use untouched stack memory, which is 0 initialize. In the latter case, you have already defined string variable, and called it's constructor. Constructor used stack memory for it's own purpose, and left those values there. Now the res variable is constructed in used stack memory, and you see some random values there.

SergeyA
  • 61,605
  • 5
  • 78
  • 137
1

It's arbitrary.

You did not initialise your variable. It has an unspecified value.

Therefore, reading its "value" has undefined behaviour. Anything can happen.

Not only can you get any value (due to internal assumptions that you cannot rationalise about from outside of the black box of the compiler implementation), but you could also/instead open a black hole or kill my cat, and I would not be terribly happy about either of those outcomes.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
0

You are outputting an uninitialized variable. So it's value can be anything.

Anon Mail
  • 4,660
  • 1
  • 18
  • 21