🚀 C++26 : The JSON Evolution Writing a JSON parser has historically been a chore. You either use a heavy library or write tedious mapping code for every single struct. C++26 is set to change the game with Static Reflection (P2996). Here is how the "JSON-to-Struct" evolution looks: 📢 Note: This code demonstrates the proposed C++26 Reflection syntax (P2996). Since the standard is still evolving, some technical details or keywords may change before the final release #cpp #programming #cpp26 #coding #softwareengineering #cleancode
Do you mean #include <meta> Please test your experiment with Godbolt. It has an experimental clang compiler that already is very feature complete and was used to write the paper.
Well, it’s nice if you would demonstrate a c++ feature - which I think you’re doing -, but if you parse this way, you’ll have O(n^2) in the number of characters (unless you fully memoize in lookup(), but then this is not the real algorithm). JSON parsers generally work the other way around: provide visitors to strings (keys) and entry/exit to lists/arrays/objects. It matters quite much if your JSON parser is in the internal loop of an event processor (network, trading, sensors, etc.), hence raising this. That said, the feature is nice and understandable indeed from your code.
In real world you would need read json from file and use default std::string, which you cannot iterate at compile time, also I think in your example compiler can optimize it without any reflections
I’m looking forward to SIMD libraries becoming more widely adopted. Unfortunately, support is still limited in Visual Studio and Clang on macOS. C# vectorization is straightforward and pleasant to use, so having similarly accessible functionality in C++ would be fantastic. The performance characteristics of C++ reflection will be particularly interesting, as it appears to be compile-time–driven, whereas C# reflection is runtime-based. That said, it remains to be seen how cumbersome this will be in practice—especially when linking and integrating across multiple libraries.
cjson is not heavy. And honestly as an c++/c/assembler programmer I am concerned of the inefficiencies the new standard wiill cause.
Robustness and speed are seldom in harmony and sometimes you need to choose. If your doing some kind of high frequency stock trading application you hope your competitors are using json
I'm glad they're finally adding reflection to C++, but man, what an horrid syntax
Good learning exercise to practise reflection, but if I ever need to deal with JSON in C++, I would prefer to use the nlohmann/json library.
So Zig’s comptime but with perl looking syntax, and compilation speed rivaling punch cards is that right
It's one of those things that business won't care less about. You know how to write json parser in C++26 using new fancy features of the language. Your cheaper competitor will ask AI to generate whatever bs code and businesses will take that instead of your smartness. Reality is that businesses don't want to have smart ppl on board. This was true all the time, you were replaced by cheaper unskilled workforce, now they replace both you and that cheap workforce altogether with AI.