11–20 of 21 posts
It is amazing how much effort is going to simplify adding "enum_to_string(e)" support in C++ or C. What is the reason this not being part of C++ standard?
This is probably an amazing library, yet the documentation gives me no clue * what the problem is that needs solving, * how the lib solves it and how that's preferable over dealing with the problem another way, * how it compares to other libs that solve the same problem. Therefore my interest in using this for my own projects right now is unfortunately close to zero.
Ah sorry about that, thanks for the feedback! I can try to answer these here (and hopefully update the documentation as well when I get the chance): - The problem is basically twofold. Part (a) is that there are no facilities for dealing with enums in C++. "Dealing with" could be anything, such as: bitwise-combining enums as flags, converting enums to/from strings, verifying that a given value is valid for an enum, d…
It is amazing how much effort is going to simplify adding "enum_to_string(e)" support in C++ or C. What is the reason this not being part of C++ standard?
All proposals for this sort of functionality are rejected as they would be subsumed by generalized compile time reflection. Which has been brewing for around 10 years and it nowhere close to be standardized.
But I believe for this type of problem it can be clarifying to begin by identifying a handful of things you should be able to do, and then baking those in. This helps because now competing proposals for how to do compile time reflection have an example application. How does your proposal make the agreed enum-to-string syntax work ? It must do that or it's not a proposal to solve the problem we agreed we have. And meanwhile the ordinary programmers get the things everybody agrees they should be able to do because we're just arguing about how those things work, not whether they should be possible.
Without this constraint, such proposals tend to wander off, each showing how they're ideally suited for solving a problem they came up with, in a context they chose, using methods they prefer, and so illuminating nothing.
A Try operator, perhaps written ?? has been proposed for C++ 26. Even if it's agreed that C++ wants this feature, you can expect years of arguing about exactly how it should work. Rust got its own Try operator ? many years ago. But the conceptual underpinning for this operator (now as the core::ops::Try trait), is still unstable and has actually been re-designed twice in that time. Ordinary Rust programmers don't need to care, they got a working operator, and they'll continue to have a working operator, only the people who care deeply about this need to spend time discussing the finer details of how that operator should be implemented.
It is amazing how much effort is going to simplify adding "enum_to_string(e)" support in C++ or C. What is the reason this not being part of C++ standard?
All proposals for this sort of functionality are rejected as they would be subsumed by generalized compile time reflection. Which has been brewing for around 10 years and it nowhere close to be standardized.
Nowadays I just keep myself to writing .NET, touching C++/WinRT as little as possible.
It needs to be a special kind of developer to love to write by hand, without any tooling support, what C++/CX reflection offered out of the box.
It is amazing how much effort is going to simplify adding "enum_to_string(e)" support in C++ or C. What is the reason this not being part of C++ standard?
Just about every non-c++ implementation depends on reflection or compile time introspection. Neither of which are in C++. So people endlessly reinvent the wheel.
Earlier quoted context omitted.
Just about every non-c++ implementation depends on reflection or compile time introspection. Neither of which are in C++. So people endlessly reinvent the wheel.
reflection is one of the C++'s committee's highest priority as they recognize it will solve a lot of problems people have. However they also know that details matter and so they need more time to get it right. C++ has more than enough cruft that doesn't quite fit together, there is no interest in adding more.
Earlier quoted context omitted.
Ah sorry about that, thanks for the feedback! I can try to answer these here (and hopefully update the documentation as well when I get the chance): - The problem is basically twofold. Part (a) is that there are no facilities for dealing with enums in C++. "Dealing with" could be anything, such as: bitwise-combining enums as flags, converting enums to/from strings, verifying that a given value is valid for an enum, d…
One other thing that have felt the need to solve was iteration through the values as if it was a container, i.e. using the range-based for loop.
for (auto const &member : enum_traits::members())
{ std::cout Earlier quoted context omitted.
All proposals for this sort of functionality are rejected as they would be subsumed by generalized compile time reflection. Which has been brewing for around 10 years and it nowhere close to be standardized.
I think WG21's process is not well suited to this type of problem. To some extent the process can't be fixed, because WG21 is a JTC1 sub-committee and so it must have - for example - the trappings of democracy (which is a bit like having a requirement that your tractor wheels must somehow be made out of blancmange). But I believe for this type of problem it can be clarifying to begin by identifying a handful of thing…
Earlier quoted context omitted.
reflection is one of the C++'s committee's highest priority as they recognize it will solve a lot of problems people have. However they also know that details matter and so they need more time to get it right. C++ has more than enough cruft that doesn't quite fit together, there is no interest in adding more.
Indeed. I first wrote an enum-to-string macro back in the late 80s in C, and again in the late 90s for C++. And here we are in 2022... still writing enum-to-string macros and the like.