Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enum class improvements for C++17, C++20 and C++23

cppstories.com

Post reply on HN
Print view View original

11–20 of 121 posts

Re: Enum class improvements for C++17, C++20 and C++23

#11

Post by jeffbee »

CarpaDorada wrote: post #10
jeffbee wrote: post #7

Odd 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`.

The expressibility of a language is what can be expressed in it, not what it can express to you. This additional feature allows you to express this projection without being explicit.

I disagree. Any language can tell the computer what to do. The quality of a good language is that it also clearly communicates to human readers.

Re: Enum class improvements for C++17, C++20 and C++23

#13

Post by rileymat2 »

jeffbee wrote: post #11
CarpaDorada wrote: post #10

Earlier quoted context omitted.

The expressibility of a language is what can be expressed in it, not what it can express to you. This additional feature allows you to express this projection without being explicit.

I disagree. Any language can tell the computer what to do. The quality of a good language is that it also clearly communicates to human readers.

I think expressiblity is trickier than that. You can think in a language with an imperative mindset where you are describing what to do, or another with a declarative mindset.

Re: Enum class improvements for C++17, C++20 and C++23

#15

Post by frozenport »

jeffbee wrote: post #7

Odd 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`.

You’re repeating the type and hoping it doesn’t change when you really just wanted the value.

Re: Enum class improvements for C++17, C++20 and C++23

#16

Post by Sharlin »

lpribis wrote: post #9

enum 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 unfixed 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)

Re: Enum class improvements for C++17, C++20 and C++23

#17

Post by westurner »

pjmlp wrote: post #8
westurner wrote: post #4

Speaking 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…

So far, most people would use whatever is provided alongside the frameworks they are already using for their application. Since the 90's, Turbo Vision, OWL, MFC, CSet++, Tools.h++, VCL, ATL, PowerPlant, Qt, Boost, JUCE, Unreal, CryEngine,.... Maybe if reflection does indeed land into C++26, something might be more universally adopted.

"Reflection for C++26" (2024) https://news.ycombinator.com/item?id=40836594

Wt:Dbo years ago but that's just objects to and from SQL, it's not linked data schema or fast serialization with e.g. Arrow.

There should be easy URIs for Enums, which I guess map most closely to the rdfs:range of an rdfs:Property. Something declarative and/or extracted by another source parser would work. To keep scheme definitions DRY

Re: Enum class improvements for C++17, C++20 and C++23

#19

Post by westurner »

beached_whale wrote: post #5
westurner wrote: post #4

Speaking 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 Serde: If you want JSON, https://github.com/beached/daw_json_link is about as close as we can get. It interop's well with the reflection(or like) libraries such as Boost Describe or Boost PFR and will work well with std reflection when it is available.

Probably not too much work to add and then also build a JSONLD @context from all of the ~ message structs.

:Thing > https://schema.org/name , :URL , :identifier and subclasses

Thing > Intangible > Enumeration: https://schema.org/Enumeration

Re: Enum class improvements for C++17, C++20 and C++23

#20

Post by bluGill »

Sharlin wrote: post #16
lpribis wrote: post #9

enum 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 )

an event loop often wants an event type enum that has defined values for internal events and then everything out of range means pass onto the users handler. There are other variations where you need to pass an enum value without caring what it mean.
Post reply on HN