3 ms·

> Rust is a really good language for writing parsers. C++ really isn’t. One thing I appreciate about writing Rust is that ADT support implies writing parsers i

> Rust is a really good language for writing parsers. C++ really isn’t. One thing I appreciate about writing Rust is that ADT support implies writing parsers is simpler under the "parse don't validate" mindset (which was clarified for me I think in this [0] article). [0]: https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

marcosdumay 4y ago
It's not ADT, it's strict types. The reason you can't do "parse, don't validate" in C++ is because you can't assume anything is valid at the point you use the data. What ADT does is give you enough flexibility so that a strict typing system doesn't suck.
- singhrac 4y ago
  > you can't assume anything is valid at the point you use the data. Just to double check my understanding: are you talking about raw pointers (i.e. void*) being common in C++ and not in Rust? You're right that I was using ADT a bit loosely; to be honest the main value add for me has been the first class data-holding enums/sum types. C++ has std::variant, but the syntax support in Rust feels nicer.
  - marcosdumay 4y ago
    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.
    - _cbsz 4y ago
      > 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 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.)
      - nemetroid 4y ago
        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);
        _cbsz 4y ago
        Ugh. You are right, and that's sad.
      - marcosdumay 4y ago
        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.

marcosdumay 4y ago

It's not ADT, it's strict types. The reason you can't do "parse, don't validate" in C++ is because you can't assume anything is valid at the point you use the data. What ADT does is give you enough flexibility so that a strict typing system doesn't suck.

singhrac 4y ago
> you can't assume anything is valid at the point you use the data. Just to double check my understanding: are you talking about raw pointers (i.e. void*) being common in C++ and not in Rust? You're right that I was using ADT a bit loosely; to be honest the main value add for me has been the first class data-holding enums/sum types. C++ has std::variant, but the syntax support in Rust feels nicer.
- marcosdumay 4y ago
  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.
  - _cbsz 4y ago
    > 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 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.)
    - nemetroid 4y ago
      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);
      - _cbsz 4y ago
        Ugh. You are right, and that's sad.
    - marcosdumay 4y ago
      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.