why does the value of d do not change?

Jan 4, 2019 at 5:43am
#include <iostream>

using namespace std;

int main()
{
int a,b, c, p, x, x1, d;
int nr=0;
cin>>a>>b>>c>>x;
x=x1;
while (x1>0)
{
p = x1 / 10;
x1 = p;
nr++;
}
d = 0;
if ((a > 1 && a < 9) && (0 < b && b < 10) && (0 < c && c < 10))
{
if (a==nr)
{
d = d + 1;
}
if (x/10==b)
{
d = d + 1;
}
if (x%10==c)
{
d = d + 1;
} }

if (d==3)
cout<<"DA";
else
cout<<"NU";
cout<<d;
return 0;
}
Jan 4, 2019 at 5:48am
ok i found out that the mistake was i initialized the x = x1 instead of x1 = x, as x1 had no value what so ever..but it still tells me d == 2, the "if x/10==b" condition doesn t work, any suggestions?
Jan 4, 2019 at 7:45am
the "if x/10==b" condition doesn t work
What make you think that it doesn't work? What are you trying to do?

I suggest that yu use debug cout to figure ot whether something does what you want or not.
Jan 4, 2019 at 11:05am
x1 had no value what so ever

That's not true. In C++, if you create an int, it has a value. You just don't know what that value is.

any suggestions?

Get the value of x. Get the value of b. Think about them.
Jan 4, 2019 at 12:58pm
x1 had no value what so ever
That's not true. In C++, if you create an int, it has a value. You just don't know what that value is.

Not sure if it should be called a value, but it certainly isn't a normal value. Using an uninitialized variable is UB.
Jan 4, 2019 at 4:41pm
It is UB, although in practical terms I'm yet to find a compiler that did anything other than simply read whatever happens to be in that memory like any other int. Some of them can be encouraged to warn about it. It would be nice if they did something spectacular instead.
Last edited on Jan 4, 2019 at 4:41pm
Jan 4, 2019 at 4:59pm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <iostream>

void f(int x)
{
	int a;
	std::cout << "a is "<< a << "\n";
	if (x == 0)
	{
		a = 1;
		std::cout << "a is set to 1\n";
	}
	std::cout << "a is " << a << "\n\n";
}

int main()
{
	for (int i : {0, 1})
	{
		f(i);
	}
}

When I compile and run the above program with GCC 7.3 using the -O2 optimization flag I get the following output.

a is 0
a is set to 1
a is 1

a is 0
a is 1

In the second case (f(1)) it looks like the value of a magically changed without being set.
Last edited on Jan 4, 2019 at 5:02pm
Jan 4, 2019 at 5:13pm
Wow, that happens to me, too. Nice example.
Jan 4, 2019 at 5:43pm
closed account (E0p9LyTq)
@Peter87,

Visual Studio 2017 won't compile your code example, errors out line 7. /W3 is default setting.

error C4700: uninitialized local variable 'a' used

TDM-GCC 5.1.0 at default warning level gives a warning about the uninitialized variable, but compiles.

Personally I'd rather have an uninitialized variable stopping compilation instead of allowing it.
Jan 4, 2019 at 5:52pm
You can make compiler-catchable uninitialized variable warnings be errors in gcc as well, I don't think that was really the point (yes, VS's project defaults are more convenient).
I totally agree it is better to make uninitialized variables be compiler errors when possible, but the point he was showing was that uninitialized variables can cause more than just a variable to be assigned -393745 instead of an actual value (the UB actually changed the apparent runtime logic of the program, halfway through the program).
Last edited on Jan 4, 2019 at 5:59pm
Jan 4, 2019 at 6:02pm
closed account (E0p9LyTq)
I know one can manually change the warning levels. I just noticed when using the default levels there is a difference in how two different compilers handle uninitialized variables.

An interesting bit of trivia how different implementations vary in small details. Nothing more.
Jan 4, 2019 at 6:05pm
Yeah, I actually did get a warning. The purpose of the program was just to give a counterexample to what Repeater said, and hopefully convince people to not rely on UB.
Jan 4, 2019 at 6:13pm
closed account (E0p9LyTq)
@Peter87, I guess I am just too a-retentive to ignore/miss a warning and think the code works as I expect.

You convinced me even more to be aware of such pitfalls. :)
Jan 5, 2019 at 8:41pm
Fair enough. What I was really trying to communicate was that bytes of memory have numbers in them even if you didn't put them there.
Last edited on Jan 5, 2019 at 9:01pm
Jan 6, 2019 at 7:54am
after meditating a bit yesterday i found the mistakes by myself, thanks for telling me about debugging, and about the "not known" value of a variable that uninitialized.
Thank you all guys for taking your time to help me out! :)
Topic archived. No new replies allowed.