7 ms·
Oof, that first example (the idiomatic C++26 way) looks so foreign if you're mostly used to C++11.
by sagacity 4mo ago
Oof, that first example (the idiomatic C++26 way) looks so foreign if you're mostly used to C++11.
- ginko 4mo agoIs it? I'm mostly used to (pre-)C++11 and the only unusual operators I see are ^^T (which I presume accesses the metadata info of T) and [:e:] (which I assume somehow casts the enumerator metadata 'e' to a constant value of T). And template for but I assume that's like inline for like in zig.
- CamouflagedKiwi 4mo agorequires is also new (not sure exactly when that appeared, it's after the last time I wrote C++ in anger) although I think it's fairly clear what it means. I can only guess at the other two. Not familiar with Zig but AFAICT `inline for` is about instructing the compiler to unroll the loop, whereas `template for` means it can be evaluated at compile time and each loop iteration can have a different type for the iteration variable. It's a bit crazy but necessary for reflection to work usefully in the way the language sets it up.
- ginko 4mo agoZig's inline for is also evaluated at comptime: https://ziglang.org/documentation/master/#inline-for https://ziglang.org/documentation/master/#inline-for
- samatman 4mo agoWell yes, but the _effect_ is to unroll the loop for runtime, if the inline-for survives that long. A for loop executed during comptime is just const stuff = comptime stuff: { for (0...8) |i| { // etc, build up some stuff } break :stuff some_stuff; }; The difference is that a comptime block won't leave behind runnable 'residue', only whatever data is constructed for later. An inline for might not leave behind an unrolled loop either, but it can.
- NooneAtAll3 4mo agorequires is concept, one of big-C-words of ++20
- randusername 4mo agoI was a fool to assume that the same forces shaping the ugliness of C++ syntax would not also be at work in C++ 26.
- mananaysiempre 4mo agoReflect/reify, quasiquote/unquote, etc. are the final boss of syntax design. Even Template Haskell looks rather bad.
- bluGill 4mo agoYou realize c++11 is closer in age to C++98 than C++26?
- mananaysiempre 4mo agoI’m not sure the nominal publication date of a standard is all that relevant when the implementors’ reaction is as lukewarm as it has been to C++ ≥20.
- delegate 4mo agoI was very curious to see what C++ 26 brings to the table, since I haven't used C++ in a while. When I saw the 'no boilerplate' example, the very first thought that came to my mind: This is the ugliest, most cryptic and confusing piece of code I've ever seen. Calling this 'no boilerplate' is an insult to the word 'boilerplate'. Yeah, I can parse it for a minute or two and I mostly get it. But if given the choice, I'd choose the C-macro implementation (which is 30+ years old) over this, every time. Or the good old switch case where I understand what's going on. I understand that reflection is a powerful capability for C++, but the template-meta-cryptic-insanity is just too much to invite me back to this version of the language.
- SuperV1234 4mo agoIt is "cryptic" and "ugly" to you just because you're not familiar with it. You'd pick the macro-based implementation because you are familiar with it. Seeing this argumentation is so tiresome, because it feels like there is a lack of self-awareness regarding what is "familiar" and what isn't, which is subconsciously translated to "ugly" and "bad".
- delegate 4mo agoHave you ever used other (modern) programming languages ? In a lot of languages, you achieve the same with 1 line of code. It's not about familiarity, it's about the fact that it's a long and convoluted incantation to get the name of an enum. Why do I have to be familiar with all those weird symbols just to do a trivial thing ? Update: Zig: const Color = enum { red, green, blue }; const name = @tagName(Color.red); // "red" Rust: #[derive(Display)] enum Color { Red, Green, Blue } let name = Color::Red.to_string(); // "Red" Clojure: (name :red) => "red"
- SuperV1234 4mo agoC++: enum Color { red, green, blue }; auto name = to_enum_string(Color::Red); // "Red"
- 4mo ago
- spacechild1 4mo agoI find it quite readable. I can understand what it does even though I haven't written reflection code yet myself.
- mort96 4mo agoI wish I understood the reason for the `std::define_static_array`... Why can't `std::meta::enumerators_of` just return something that can be iterated through????
- SuperV1234 4mo agoIt is kind of weird at first but the reason is that `std::vector` requires heap allocation and transient allocations are not allowed in `constexpr` contexts. The purpose of `std::define_static_array` is to promote the storage of the vector to static storage to eliminate the transient allocation issue, and so that the `template for` can work properly with it. See wg21.link/P3491
- mort96 4mo agoIs there a reason why `std::meta::enumerators_of`, a reflection feature that's surely almost exclusively going to be used in constexpr contexts, returns a value which doesn't work in constexpr contexts?
- SuperV1234 4mo agoIt works generally, but not with expansion statements. See section 3.2 here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p1306r4.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p13... It seems that this is being worked on, and eventually the `define_static_array` won't be needed anymore