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

101–110 of 121 posts

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

#101

Post by tialaramex »

zelphirkalt wrote: post #87
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 "…

Why is an enum a class? What does that even mean semantically? Why can't an enum simply be ... an enum? Even if under the covers an enum is/was implemented as a special class, why would the language syntax leak this implementation detail to the programmer? Perhaps it would be cleaner to make enum its own concept, rather than trying to shoehorn it into classes. It is a fundamentally different thing than a class after…

Because C++ has no way to compatibly adjust its syntax, it's important to them to reuse keywords where possible.

So enum and class were two existing keywords whereas scoped would be a new keyword.

There's also a sentiment among C++ proponents that classes (a user defined product type with implementation inheritance) are all you really need anyway.

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

#102

Post by soegaard »

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.

"On the expressive power of programming languages"

Matthias Felleisen

https://jgbm.github.io/eecs762f19/papers/felleisen.pdf

Abstract

The literature on programming languages contains an abundance of informal claims on the relative expressive power of programming languages, but there is no framework for formalizing such statements nor for deriving interesting consequences. As a first step in this direction, we develop a formal notion of expressiveness and investigate its properties. To validate the theory, we analyze some widely held beliefs about the expressive power of several extensions of functional languages. Based on these results, we believe that our system correctly captures many of the informal ideas on expressiveness, and that it constitutes a foundation for further research in this direction.

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

#103

Post by Nullabillity »

bluGill wrote: post #100
Nullabillity wrote: post #27

Earlier quoted context omitted.

This isn't rocket science once you have sum types. enum Event { System(SystemEvent), User(T), }

At least in C++ a template needs to be known at compile time, but I want to build my event loop and latter add in more values that should be handled without rebuilding it.

You could make your `T` type as dynamic as you want it to be.

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

#104

Post by Nullabillity »

account42 wrote: post #77
Nullabillity wrote: post #27

Earlier quoted context omitted.

This isn't rocket science once you have sum types. enum Event { System(SystemEvent), User(T), }

Using Rusts' retarded enum keyword for your example doesn't exactly make your point understandable, especially when talking in the context of actual enumerations. Anyway, the point of what gp describes is to do this in a single integer without overhead so a naive sum type is not the solution.

> Using Rusts' retarded enum keyword for your example doesn't exactly make your point understandable, especially when talking in the context of actual enumerations.

    data Event = System SystemEvent | User a
> Anyway, the point of what gp describes is to do this in a single integer without overhead so a naive sum type is not the solution.

Virtually all event systems end up carrying auxilary event data of some form, so sum types are what you want regardless.

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

#105

Post by Maxatar »

OvbiousError wrote: post #68
maattdd wrote: post #35

Earlier quoted context omitted.

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;

You seem to have a very narrow C++ view of what sum types are. Sum types are related to the expression problem, and the given example is the canonical instance of the expression problem.

https://en.wikipedia.org/wiki/Expression_problem

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

#106

Post by Maxatar »

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 first is more expressive, the second is more explicit.

The expressiveness of an expression allows it to be used in more contexts, such as in generic code where the underlying type may not be known.

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

#107

Post by consteval »

Thiez wrote: post #95
account42 wrote: post #66

Earlier quoted context omitted.

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

One of those cases happens accidentally all the time (in more complex variants than the motivating example you responded to), the other never happens except on purpose. It's like complaining guard rails are pointless because people being launched with catapults might still fly over them and plunge to their deaths.

I've never seen a nullptr somehow sneak into a reference. Never.

What I have seen is automatic variables escaping their scope as a reference, which rust protects against. And is also much more dangerous, because dereferencing a nullptr is defined behavior on most platforms

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

#109

Post by consteval »

account42 wrote: post #93
Lvl999Noob wrote: post #61

Earlier quoted context omitted.

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

Putting using statements inside small functions is the opposite of ehancing readbility.

I disagree, because the scope doesn't escape those functions and it can greatly reduce the amount of ::

Usually in an entire codebase or a module there's a lot of competing, similar symbols. But in a function that's not the case, because they do something small. So there's no benefit to being more "explicit", because the function already states what it does.

For example you might not want to use std::chrono. But in, say, a series of timing functions you really don't want to be writing std::chrono:monotonic_clock::now(), do you? You can just use a using and then just call now() or whatever.

Post reply on HN