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.
They most certainly can be null as can “this”.
Enum class improvements for C++17, C++20 and C++23
41–50 of 121 posts
Re: Enum class improvements for C++17, C++20 and C++23
#42Re: Enum class improvements for C++17, C++20 and C++23
#43Earlier quoted context omitted.
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
Adding reflection will be simple and backwards compatible with existing code as it would only come into play when someone hasn't manually mapped a type. This leaves the cases where reflection doesn't work(private member variables) still workable too.
Haven't looked at JSONLD much, but it seems like it could be added but would be a library above I think. Extracting the mappings is already doable and is done in the JSON Schema export.
Re: Enum class improvements for C++17, C++20 and C++23
#44enum 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 "…
What the alternative? Let’s say you have a file, you parse a uint32_t, and you want to convert that into the Handle type. If the enum is closed how do you do it? Giant switch? That would break the fundamental principle that C++ abstractions are zero-cost.
Re: Enum class improvements for C++17, C++20 and C++23
#45enum 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 "…
What the alternative? Let’s say you have a file, you parse a uint32_t, and you want to convert that into the Handle type. If the enum is closed how do you do it? Giant switch? That would break the fundamental principle that C++ abstractions are zero-cost.
I don't think that "abstractions are zero cost" necessarily applies to every serialization format you could choose to use, or to any other thing that isn't part of the language.
If you want to guarantee that some value is within the allowed range of values, normally you'd have to run some code to do that, yes.
Re: Enum class improvements for C++17, C++20 and C++23
#46All that crap is the reason I never bother with enums in all these C like languages
set_player_color(player, .RED);
set_color(Color::RED);
It's one of the things I love about Swift and Zig
int main() {
using enum ComputeStatus;
ComputeStatus s = NotEnoughMemory;
}
Re: Enum class improvements for C++17, C++20 and C++23
#47enum 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…
While I'm not necessarily sold on making tons of stuff UB in release builds and checked in debug builds, it seems maybe better than not having exhaustive enums at all. Here's an example of this feature from some other language: https://ziglang.org/documentation/master/#enumFromInt
Re: Enum class improvements for C++17, C++20 and C++23
#48Earlier quoted context omitted.
What the alternative? Let’s say you have a file, you parse a uint32_t, and you want to convert that into the Handle type. If the enum is closed how do you do it? Giant switch? That would break the fundamental principle that C++ abstractions are zero-cost.
I don't think that "abstractions are zero cost" necessarily applies to every serialization format you could choose to use, or to any other thing that isn't part of the language. If you want to guarantee that some value is within the allowed range of values, normally you'd have to run some code to do that, yes.
It applies to the enum. If you couldn’t lift an integer into the enum without branching, then the enum isn’t zero cost - it requires more resources than C would to do the same thing. Bounds checking is never mandatory in C++.
When C++ has broken this rule, developers have tended to turn those features off or ban them in style guides.
Re: Enum class improvements for C++17, C++20 and C++23
#49Re: Enum class improvements for C++17, C++20 and C++23
#50Earlier quoted context omitted.
I don't think that "abstractions are zero cost" necessarily applies to every serialization format you could choose to use, or to any other thing that isn't part of the language. If you want to guarantee that some value is within the allowed range of values, normally you'd have to run some code to do that, yes.
It applies to the enum. If you couldn’t lift an integer into the enum without branching, then the enum isn’t zero cost - it requires more resources than C would to do the same thing. Bounds checking is never mandatory in C++. When C++ has broken this rule, developers have tended to turn those features off or ban them in style guides.
Providing exhaustive enums wouldn't prevent the language from providing non-exhaustive enums or users from placing values into them cheaply using memcpy.