Hacker News Reader

Comment by marcosdumay | Hacker News Reader

C++ has a series of issues.

You can't trust pointers have a value, or that the value is valid, you can't trust that your enums have a value inside their interval, or in fact you can't trust that any value from any type is inside its interval at all.

You also can't really trust that your values have the correct size.

We choose some of those to ignore, otherwise we wouldn't be able to program at all, but C++ gives you no guarantees at all about anything. The point is that if you do a parsing run in C++ and encode your value, you will still get many of the above problems because of bugs in your code.

View on HN

> you can't trust that your enums have a value inside their interval

If you don't set the underlying type, assigning a value that doesn't match an enumerator via `static_cast` is undefined behavior. See https://en.cppreference.com/w/cpp/language/enum . (Doing weird pointer casting things is also undefined behavior per the strict aliasing rule, though, come to think of it, I'm not sure whether memcpying an out-of-range value into an enum through the "reinterpret_cast to `char*`" loophole is undefined behavior.)

I’m assuming you are referring to this part:

> If the underlying type is not fixed and the source value is out of range, the behavior is undefined.

Note the fine print about the meaning of ”out of range”:

> (The source value, as converted to the enumeration's underlying type if floating-point, is in range if it would fit in the smallest bit field large enough to hold all enumerators of the target enumeration.)

So this is not undefined:

  enum E { A = 0, B = 1, C = 2 };
  E valid = static_cast<E>(3);

Ugh. You are right, and that's sad.

Even if that covered all the problem space (instead of replacing it with a much larger one), if your code is flawless, parsing and validating are equivalent.

Choosing one just makes a difference because code has problems.

Reply on news.ycombinator.com