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

61–70 of 121 posts

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

#61

Post by Lvl999Noob »

WhereIsTheTruth wrote: post #46

All that crap is the reason I never bother with enums in all these C like languages set_player_color(player, .RED); That should be the way to use them, it's concise and typesafe set_color(Color::RED); Why repeat yourself? It's one of the things I love about Swift and Zig int main() { using enum ComputeStatus; ComputeStatus s = NotEnoughMemory; } now you have polluted the scope.. C++ have lost the plot.. they understo…

> now you have polluted the scope

Actually they haven't. Using glob imports inside small functions can enhance readability without causing confusion. Otherwise any kind of aliasing and importing would be polluting the scope since they are bringing other items into your module without the full path.

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

#63

Post by gpderetta »

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…

> and obviously cannot work once you realize that std::variant is just syntax sugar over a tagged union

It would be easy to make it work, there isn't necessarily a strict relation between the template parameter and the actual stored object. Not having reference variant members was a conscious decision, same as optional. Hopefully this will be fixed in the future.

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

#64

Post by gpderetta »

Lvl999Noob wrote: post #58
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 "…

I don't know C++ too deeply but from the little bit in the article, it seems like these `enum class` enums are actually Newtypes with associated constants instead of actual enumerations. They clearly don't 'enumerate' all possible values but they do give different behavior from their underlying type. Is it possible to override the constructor so it limits the allowed values? Implement other methods on the `enum class…

> `enum class` enums are actually Newtypes

They indeed are. I find myself using enums classes as strong typedefs more often than actual enums.

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

#65

Post by gpderetta »

Thorrez wrote: post #56
Sharlin wrote: post #16

Earlier quoted context omitted.

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 )

It wasn't unfixed in C++17. The problem existed before C++17. 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}.

IIRC for a brief period GCC considered values outside of the enumeration as UB and heavily optimized according to this. At some point this interpretetion made it as far as at least a draft standard. Then it got reverted as it went against decades of common usages and instead the opposite was made explicit in the standard.

Making it UB for enum classes was considered, but the strongly typeded alias use case was considered safer and more useful.

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

#66

Post by account42 »

LowLevelMahn wrote: post #55
robmccoll wrote: post #40

Earlier 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); }

And you can also open /proc/self/mem in a Rust program and overwrite whatever you want, including pointers. So?

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

#67

Post by gpderetta »

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; }

The expression problem enters the room.

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

#68

Post by OvbiousError »

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; }

You should probably look up what a sum type is, it has nothing to do with summations. Your example doesn't contain a sum type. A C++ example:

    std:variant sum_type_instance = 5;

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

#69

Post by OvbiousError »

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.

Indeed. There seems to be quite the lack of understanding what the mentioned concepts actually are.
Post reply on HN