Program Behaving Strangely on Online Ides

Program behaving strangely on online IDEs

I'm going to assume that the online compilers use GCC or compatible compiler. Of course, any other compiler is also allowed to do the same optimization, but GCC documentation explains well what it does:

-faggressive-loop-optimizations

This option tells the loop optimizer to use language constraints to derive bounds for the number of iterations of a loop. This assumes that loop code does not invoke undefined behavior by for example causing signed integer overflows or out-of-bound array accesses. The bounds for the number of iterations of a loop are used to guide loop unrolling and peeling and loop exit test optimizations. This option is enabled by default.

This option merely allows making assumptions based on cases where UB is proven. To take advantage of those assumptions, other optimizations may need to be enabled, such as constant folding.

---

Signed integer overflow has undefined behaviour. The optimizer was able to prove that any value of i greater than 173 would cause UB, and because it can assume that there is no UB, it can also assume that i is never greater than 173. It can then further prove that i < 300 is always true, and so the loop condition can be optimized away.

Why 4169 and not some other value?

Those sites probably limit the number of output lines (or characters or bytes) they show and happen to share the same limit.

floor() behaving strangely

Here's the output, using printf instead:

printf("%.15f\t%.15f\t%.15f\n", a, a + 0.5, floor(a + 0.5));

The imprecision is clear now:

10.000000000000000  10.500000000000000  10.000000000000000
10.100000000000000  10.600000000000000  10.000000000000000
10.199999999999999  10.699999999999999  10.000000000000000
10.299999999999999  10.799999999999999  10.000000000000000
10.399999999999999  10.899999999999999  10.000000000000000
10.499999999999998  10.999999999999998  10.000000000000000
10.599999999999998  11.099999999999998  11.000000000000000
10.699999999999998  11.199999999999998  11.000000000000000
10.799999999999997  11.299999999999997  11.000000000000000
10.899999999999997  11.399999999999997  11.000000000000000

Undefined Behaviour in C++

Your platform most likely has a 32 bit int. So 1'000'000'000 is an int, and the compiler will attempt to evaluate i * 1'000'000'000 as an int too. This results in an overflow from i being 3 onwards.

The behaviour on overflowing a signed integral type is undefined.

Note that this makes the entire program behaviour undefined, which accounts for the multiple lines of output (beyond 10) that you observe.

(If you had chosen 10'000'000'000 say instead then the multiplication would have been evaluated with long long types and the behaviour would be well-defined!)

Bar graph program behaving strangely

The program is just finishing normally - put a call to cin.getline or some other input call if you want it to wait. Alternatively run it through the debugger and put a breakpoint on the return 0 line.

You don't initialize or reset printedStars before you use it. Put printedStars = 0; before your star printing loops.

Move the setw(5) bit in the cout calls to before the value, so the value is output with a width of 5.

Why is the phrase: undefined behavior means the compiler can do anything it wants true?

Nothing "causes" this to occur. Undefined behaviour cannot "occur". There is no mystical force that descends upon your computer and suddenly makes it create black holes inside of cats.

That anything can happen when you run a program whose behaviour is undefined, is stated as fact by the C++ standard. It's a statement of leeway, a handy excuse used by compilers to make assumptions about your code so as to provide useful optimisations.

For example, if we say that dereferencing nullptr is undefined (which it is) then no compiler needs to ever check that a pointer is not nullptr: it can just assume that a dereferenced pointer will never be nullptr, and if it's not then any consequences are the programmer's problem.

Due to the astounding complexity of compilers, some of those consequences can be rather unexpected.

Of course it is not actually true that "anything can happen". Your computer has neither the necessary physical power nor the necessary legal authority to instantiate a black hole inside of a cat. But since C++ is an abstraction, it seems only fitting that we use abstractions to teach people not to write programs with undefined behaviour. If you program rigorously, assuming that "anything can happen" if your program has undefined behaviour, then you will not be surprised by said rather unexpected consequences, and you will not be tempted to try to "control" the outcome in any way.

Reading Registry in Windows 7 behaving strangely

You can specify the flag::

1. "KEY_WOW64_32KEY" in "samDesired" parameter of the RegOpenKeyEx if you want to access Wow6432Node Keys i.e., 32-bit keys from your app.
2. "KEY_WOW64_64KEY" in "samDesired" parameter of the RegOpenKeyEx if you want to access normal Keys i.e., 64-bit keys from your app.

Note:: Your doubt has already been cleared by @WhozCraig in comments with the suitable links. If he answers, do accept his answer over mine.

Qt - QTreeView starts behaving strangely over time of running the application

I think this is a known bug and that it is fixed in Qt5.6.1 release. See here for details of the bug - it looks like what you are seeing (or very similar).

So try to updating to Qt5.6.1 and see if this resolves it.

---

Related Topics