Hacker News Reader

> int x = void;

this is what the D programming language does. Every var declaration has a well know value, unless it is initialized with void. This is nice, optimizing compilers are able to drop useless assignments anyway.

Nah, they'd never add new syntax like that, given it's inconsistent with the rest of C++.

If they added an explicit uninitialized value representation to the language, I bet it would look something like this:

  int x {std::uninitialized<int>::value};

You're not far off. In C++26 the syntax will be:

   int x [[indeterminate]];

I'm not kidding here;

C++ hasn't done it this way for nullptr or nullopt, why would it do it for an explicit uninitialized?

I guess nullptr was put in there because because because "#define NULL 0" had some bad consequences for C++ and they needed a replacement.

std::nullopt doesn't seem so different to what I was talking about; I guess it's just less verbose. When I wrote that, I was thinking of things like "std::is_same<T1, T2>::value" being there.

That's about the right level of ceremony to request an uninitialized variable.

How about int x = 0 if you want 0. Just `int x;` doesn't make it clear that you want 0.

Safe defaults matter. If you're using x to index into a array, and it's randomly initialized as +-2,000,000,000 because that's what happened to be in that RAM location when the program launched, and you use it before explicitly setting it, you're gonna have a bad time.

And if you used it with a default value of 0, you're going to end up operating on the 0th item in the array. That's probably a bug and it may even be a crasher if the array has length 0 and you end up corrupting something important, but the odds of it being disastrous are much lower.

The whole advantage of UB is that this places less restraints on what the optimizer can do. If I say something does not need to be initialized I am giving the optimizer the freedom to do more!

So what's the issue with introducing explicit syntax to do exactly that if you want to? A safe default does not preclude you from opting out of safety with a bit of syntax or perhaps a compiler flag.

The issue is that the language was already designed with the old behavior.

> It's so ironic hearing a comment like this. If what you really want is for C++ to do only what you strictly specified, then you'd always release your software with all optimizations disabled

The whole idea of optimizations is producing code that’s equivalent to the naiive version you wrote. There is no inconsistency here.

Optimizations are not "exactly and only what the programmer specifies and no more". They actually fall into the "more" category, believe it or not.

Show me some O2 optimizations that will act contrary to code I wrote - meaning they violate the “as if” rule.

Two points... the first is you want an optimization that violates the "as if" rule, sure... copy constructors are allowed to violate the "as if" rule, so here you go:

    https://godbolt.org/z/jzWWTW85j

Compile that without optimizations and you get one set of output, compile it with optimizations and you get another. There are actually an entire suite of exceptions to the "as-if" rule.

The second point is that the whole reason for having an "as if" rule in the first place is to give permission for the compiler to discard the literal interpretation of the source code and instead only consider semantics that are defined to be observable, which the language standard defines not you the developer.

There would be no need for an "as if" rule if the compiler strictly did exactly what it was told. Its very existence should be a clue that the compiler is allowed to reinterpret the source code in ways that do not reflect its literal interpretation.

The standard says that "Copy elision is <...> one of the two allowed forms of optimization, alongside allocation elision and extension,(since C++14) that can change observable side-effects"

I agree you have a valid point though. I'd be interested to know the committee's reasoning.

> if the compiler strictly did exactly what it was told.

What does this mean since I am not writing assembly and there is no specified correspondence between assembly and C++.

Nothing about my post has anything to do with assembly. You asked for, and I quote "Show me some O2 optimizations that will act contrary to code I wrote - meaning they violate the “as if” rule." and I provided just that. You can go on the link I provided, switch back and forth between O2 and O0 and see different observable behavior which violates the as-if rule.

I'm not sure why you're bringing up assembly but it suggests that you might not correctly understand the example I provided for you, which I reiterate has absolutely nothing to do with assembly.

I dunno about what you wrote, but here is one that clearly violates what OP said!

https://godbolt.org/z/Y4Yjb7z9c

clang notices that in the second loop I'm multiplying by 0, and thus the result is just 0, so it just returns that. Critically, this is not "exactly and only what the programmer specifies", since I very much told it to do all those additions and multiplications and it decided to optimize them away.

What? But the result is the same!