Earlier quoted context omitted.
Just use std::variant References in C++ are just sugary pointers.
References have one important property over pointers. They cannot be null.
Enum class improvements for C++17, C++20 and C++23
51–60 of 121 posts
Re: Enum class improvements for C++17, C++20 and C++23
#52Speaking of enums, what's a better serialization framework for C++ like Serde in Rust, and then what about Linked Data support and of course also form validation. Linked Data triples have (subject, predicate, object) and quads have (graph, subject, predicate, object). RDF has URIs for all Subjects and Predicates. RDF Objects may be URIs or literal values like xsd:string, xsd:float64, xsd:int (32bit signed value), xsd…
Re: Enum class improvements for C++17, C++20 and C++23
#53enum class Handle : uint32_t { Invalid = 0 }; Handle h { 42 }; // OK One of their examples demonstrates the number one issue for me with enums, which was not fixed with `enum class`. Since values outside the range of the type are valid, you are constantly needing to check for invalid values in any function that takes an enum [class]. Ruins any attempt at "parse, don't validate" style in c++ and completely ruins the "…
You can easily build your own safe enum on top of you really want.
Edit: someone else pointed out the bitmask use case else thread. Strongly typed integrals is also a common use case.
Re: Enum class improvements for C++17, C++20 and C++23
#54Re: Enum class improvements for C++17, C++20 and C++23
#55Re: Enum class improvements for C++17, C++20 and C++23
#56enum class Handle : uint32_t { Invalid = 0 }; Handle h { 42 }; // OK One of their examples demonstrates the number one issue for me with enums, which was not fixed with `enum class`. Since values outside the range of the type are valid, you are constantly needing to check for invalid values in any function that takes an enum [class]. Ruins any attempt at "parse, don't validate" style in c++ and completely ruins the "…
Well, apparently it was fixed with `enum class`… until it was un fixed in C++17 for unfathomable reasons. It’s honestly crazy that C++ doesn’t have simple exhaustiveness-checked enums. The obvious actual solution for the valid use case of deserializing an enum from an integer would be something like template std::optional from_underlying(std::underlying_type ) requires(std::is_enum_v )
This is valid code in C++11:
enum class Foo : int { Invalid = 0 };
Foo f = Foo(5);
In C++11, this compiles with Foo(5) but not Foo{5}. In C++17, this compiles with both Foo(5) and Foo{5}.Re: Enum class improvements for C++17, C++20 and C++23
#57Odd that it says auto value = std::to_underlying(p); // C++23 is "more expressive" than uint8_t value = static_cast (Permissions::Read); The latter seems clearly more expressive, not less. You could tighten it up a bit by using auto on the LHS instead of the redundant uint8_t. In the former I don't know what's going on and I have to go read another header to figure out the type of `value`.
Re: Enum class improvements for C++17, C++20 and C++23
#58enum class Handle : uint32_t { Invalid = 0 }; Handle h { 42 }; // OK One of their examples demonstrates the number one issue for me with enums, which was not fixed with `enum class`. Since values outside the range of the type are valid, you are constantly needing to check for invalid values in any function that takes an enum [class]. Ruins any attempt at "parse, don't validate" style in c++ and completely ruins the "…
Is it possible to override the constructor so it limits the allowed values? Implement other methods on the `enum class`? If so then that makes them still very useful, albeit not in the usual `enum` sense.
Re: Enum class improvements for C++17, C++20 and C++23
#59Earlier quoted context omitted.
References have one important property over pointers. They cannot be null.
they easily can :) void test(int& y){} int main() { int* x = nullptr; test(*x); }