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

31–40 of 121 posts

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

#31

Post by galkk »

fgkhax wrote: post #30
MawKKe wrote: post #25

Earlier quoted context omitted.

IMO that's the typical experience with many of the features in modern C++ standards. You read about a really neat useful thing they added, something that seems to provide a safe and practical way to overcome a shortcoming in the language. You may even get a little excited...until you try to actually use it and realize its full of new footguns and weird limitations

Yes, you read about std::variant on a blog and think that it is a sum type. Then you try it out and realize that it's a thin (type-safe) wrapper over tagged unions that is at least three times slower and has about 5 unreadable alternatives that replace simple switch statements. Then you find out that members of a "variant" are not really variant members but just the individual types that can be assigned to a union. F…

Ohh, and to make the use of a variant to look like pattern match over type you need to copy paste some template magic.

https://schneide.blog/2018/01/11/c17-the-two-line-visitor-ex...

variants are a such disappointment at every step of trying to use them

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

#32

Post by nly »

fgkhax wrote: post #30
MawKKe wrote: post #25

Earlier quoted context omitted.

IMO that's the typical experience with many of the features in modern C++ standards. You read about a really neat useful thing they added, something that seems to provide a safe and practical way to overcome a shortcoming in the language. You may even get a little excited...until you try to actually use it and realize its full of new footguns and weird limitations

Yes, you read about std::variant on a blog and think that it is a sum type. Then you try it out and realize that it's a thin (type-safe) wrapper over tagged unions that is at least three times slower and has about 5 unreadable alternatives that replace simple switch statements. Then you find out that members of a "variant" are not really variant members but just the individual types that can be assigned to a union. F…

A few code snippets of what you see as weaknesses of std::variant may be appropriate, as I couldn't figure out your complaint. Assigning to a variant taken by non-const& works fine for me.

I personally would have liked to see recursive variant types and multi-visitation (as supported by boost::variant).

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

#33

Post by nly »

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…

Boost Fusion or Boost Hana + whatever serialization library you want to use is probably best imho.

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

#34

Post by amluto »

nly wrote: post #32
fgkhax wrote: post #30

Earlier quoted context omitted.

Yes, you read about std::variant on a blog and think that it is a sum type. Then you try it out and realize that it's a thin (type-safe) wrapper over tagged unions that is at least three times slower and has about 5 unreadable alternatives that replace simple switch statements. Then you find out that members of a "variant" are not really variant members but just the individual types that can be assigned to a union. F…

A few code snippets of what you see as weaknesses of std::variant may be appropriate, as I couldn't figure out your complaint. Assigning to a variant taken by non-const& works fine for me. I personally would have liked to see recursive variant types and multi-visitation (as supported by boost::variant).

I think the comment means:

    std::variant
does not work well.

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

#35

Post by maattdd »

searealist wrote: post #28
tialaramex wrote: post #26

Earlier quoted context omitted.

I don't think they're complaining that Sum types are equivalent to any or all of those things, but rather that what they wanted was Sum types and C++ has given them all this other stuff claiming it will solve their problem, instead of a Sum type which does solve the problem. If what I need is a bookshelf then it's true that a wardrobe, a cardboard box, a Kindle, and a shredder are all different things and a bookshelf…

It makes no sense to mention dyanmic_cast or inheritance (clearly referencing virtual functions here) when languages with sum types also have equivalents. It just shows a misunderstanding of how these features are used. I don't think I've ever seen an analogy contribute to a discussion, and yours is no exception.

Inheritance (the subtyping part of it) is considered the OOP way to write sum type.

sum Expr { Int; Add(Int,Int) }

VS

class Expr { }

class Add extends Expr { Expr left; Expr right; }

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

#36

Post by nly »

amluto wrote: post #34
nly wrote: post #32

Earlier quoted context omitted.

A few code snippets of what you see as weaknesses of std::variant may be appropriate, as I couldn't figure out your complaint. Assigning to a variant taken by non-const& works fine for me. I personally would have liked to see recursive variant types and multi-visitation (as supported by boost::variant).

I think the comment means: std::variant does not work well.

Just use

    std::variant
References in C++ are just sugary pointers.

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

#37

Post by patrick451 » 

    enum class Handle : uint32_t { Invalid = 0 }; 
    // process({10}); // error
    process(Handle{10});
> In C++14, you could use process(static_cast(10)); so, as you can see, the C++17 version is much better.

100% disagree that the c++17 version is better. It just lets you right broken code that doesn't look broken.

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

#38

Post by layer8 »

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

The main difference between old ("unscoped") and new ("scoped") enums, besides dropping implicit conversions from/to integral types, is the scope of the named constants. With unscoped enums, the constants are in the surrounding scope, which means that constants with the same name but of different enum types collide with each other. One solution is to wrap them in a dummy struct or class (`struct Foo { enum Bar { baz = 0 } }` => `Foo::baz`). Scoped enums are more or less a shortcut for that, where with `enum class Foo { bar }` you have to write `Foo::bar`, or you can use `using enum Foo` to be able to write plain `bar` again.

The reason other values of the underlying integral type beyond the named ones are allowed, is that enums are often used to specify bit values or bit masks that you AND/OR with each other. It is what it is.

The other question is, how would you go about converting an integral value to an enum type if only specific values were allowed? Either you need an explicit case distinction (potentially large switch) for all the allowed values, or there would have to be a hidden structure/array specifying the valid values at runtime, generated by the compiler. C++ is rather conservative in adding such runtime structures.

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

#39

Post by searealist »

maattdd wrote: post #35
searealist wrote: post #28

Earlier quoted context omitted.

It makes no sense to mention dyanmic_cast or inheritance (clearly referencing virtual functions here) when languages with sum types also have equivalents. It just shows a misunderstanding of how these features are used. I don't think I've ever seen an analogy contribute to a discussion, and yours is no exception.

Inheritance (the subtyping part of it) is considered the OOP way to write sum type. sum Expr { Int; Add(Int,Int) } VS class Expr { } class Add extends Expr { Expr left; Expr right; }

That's not C++.

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

#40

Post by robmccoll »

nly wrote: post #36
amluto wrote: post #34

Earlier quoted context omitted.

I think the comment means: std::variant does not work well.

Just use std::variant References in C++ are just sugary pointers.

References have one important property over pointers. They cannot be null.
Post reply on HN