I don't know why there's all of this hate for clear enunciation and deliberate trains of thought. I watched (listened, mainly) while tending the grill on a loud windy day, so it was helpful. On to the meat of the video, I have no idea why I might potentially use this in the future, but I do know that I've wanted something similar to this in the past. So on behalf of future me, I thank you for the extra tool on my belt for use whenever the need arises.
Agreed. The solution is simple - bump up the speed if you want to go faster. I myself go at 1.5x, but it seems a little petty for someone to go out of their way to complain about something they have a fair amount of control over.
Nice. I imagine you could also make the program convert the JSON to a static class/struct and have the compilation access the data by name instead of by key.
When working with 'webpack' and other JS bundling tools, there are options for configuring transformers that pre-process imports (of any filetype theoretically, as long as you can write a transformer) into javascript code. I wonder if something like this combined with the #embed proposal could be useful? Of course, this would mean a hell of a lot more constexpr support in the compiler, and is really helped for the JS case since Node is both the target environment and the environment running the build tools.
sorry, my question iscompletely unrelated to the video, but one day I needed to reemplement the std::optional, to somewhat cover the std::optional case. So I did a wrapper around std::aligned_storage, and everything seemed to be working fine, but then address sanitizer stated, that I had a bunch of "use after free" cases with that aligned storage. I started digging up the std library implementation of the optional and found out about the std::launder. I slapped that thing to my optional, and it magically fixed those uses after free. Can you clear that out for me, please? The cppref article about std::launder didn't help at all
The raw strings shouldn't be necessary. JSON defines member names as valid JSON strings, so that is utf8 with only a few escapes that are needed(values
I’m puzzled by why I would want to specify configuration that is known at compile time in a different language. I suspect there is a good reason, but I haven’t yet found a case myself where I wasn’t better off factoring out a configuration source file in the language of the code it was configuring. What am I missing here?
It can reduce boilerplate and increase interoperability with other systems and languages. If the configuration is in JSON, it can more easily be generated or manipulated by other, automatic tools than source code. Usually you break out configuration like this when it becomes big enough that you don't enjoy doing it by hand.
Why don't you simply escape backslashes and double quotes and include your string constants into ordinary double quotes? How do you handle unicode characters?
So what is the use case for this? Am I correct in assuming it's just to incorporate a local JSON file into a C++ application by creating a class that has all it's data? So where would this be useful? Don't the majority of applications consume JSON at runtime? Possibly you have a web service that hits an API endpoint and gets load of data. That JSON has to be parsed at runtime. What you can do is maybe create a structure that would hold easily that JSON (somehow) but creating this data structure for something you have locally... not seeing how useful that is to the majority of people. If you have a massive JSON for configuration consider changing to SQLite or something. Maybe I'm missing something here....
It's called "cross training." Runners have to also weight lift if they want to become better runners. This is true of C++ as well. You sharpen your C++ by exposing yourself to other concepts outside of the language.
@ok I see! So for the compile time checks, you would need to include the *_impl.hpp, and for the runtime access (with zero overhead) you just need the *.hpp.
Compile time json converter is nice. But in the real world, the json files are read by the application during start up and they are converted to classes. Normally, servers are brought up much ahead of actual business time. In that case, what advantage does this bring?
I write simulators. High-fidelity simulators can take a _looooong_ time to start up due to heavy configuration, even for scenarios that might run in less time than they took to set up. I could easily see this being used to pre-compile scenario configurations as shared libraries and load them using dlopen. It would slow down scenario development, but scenarios are usually run far more often than they are changed and tested. It would also be easy enough to provide a "hot load" option that uses the JSON directly and sacrifices startup time for last-minute changes and scenario development.
It's funny that they are appearing now. He's always used this pace in his videos, and I don't ever recall comments about it. I like to set the speed to 1.5, but it never occurred to me to complain about it. His style works great and youtube features can easily adjust the pace to each listener's preferences.
As a foreign viewer, I particularly appreciate how Jason speaks, I can understand what he says without reading subtitles. Don't change anything Jason !
For those of you that don't understand why this might be useful, you don't work with a resource constrained system that would clearly benefit from this. This video is not for you unless you want to play around with the techniques used or learn how to use them better. Jason mentions at least two examples where something like this could be useful.
@ok, those compilers will also not support C++17/20/23, but for some reason you didn't say this JSON library is at fault by using these modern standards. Supporting shit compilers requires writing shit code, which, luckily, is not the scope of this channel.
@ok, I challenge you to find an example of a compiler that supports C++17 and doesn't support pragma once. I very seriously doubt one exists, and I don't understand why you're being so dense about it.
@ok, and more importantly, you call it a minor stylistic decision, but I call it proliferation and perpetuation of bad coding practice. Obviously, you've never hunted down a bug caused by clashing include guards, so it is you who has little experience.
Ah yes, C++ Weekly with JSON Turner
I don't know why there's all of this hate for clear enunciation and deliberate trains of thought. I watched (listened, mainly) while tending the grill on a loud windy day, so it was helpful.
On to the meat of the video, I have no idea why I might potentially use this in the future, but I do know that I've wanted something similar to this in the past. So on behalf of future me, I thank you for the extra tool on my belt for use whenever the need arises.
Agreed. The solution is simple - bump up the speed if you want to go faster. I myself go at 1.5x, but it seems a little petty for someone to go out of their way to complain about something they have a fair amount of control over.
I'm not gonna lie, I leave my playback speed untouched for every video I watch, instead of this one.
You should definetely rename it to JSON to CPP Turner
Absolutely underrated comment
Nice. I imagine you could also make the program convert the JSON to a static class/struct and have the compilation access the data by name instead of by key.
I think this tool has so much potential, great work!
When working with 'webpack' and other JS bundling tools, there are options for configuring transformers that pre-process imports (of any filetype theoretically, as long as you can write a transformer) into javascript code. I wonder if something like this combined with the #embed proposal could be useful? Of course, this would mean a hell of a lot more constexpr support in the compiler, and is really helped for the JS case since Node is both the target environment and the environment running the build tools.
But I thought that Jason converted to C++ a long time ago
Haha, good one 😂
He’s a Json Turner indeed.
Since it has the same API as nlohmann, could you simply use their test suite?
Great idea.
sorry, my question iscompletely unrelated to the video, but one day I needed to reemplement the std::optional, to somewhat cover the std::optional case. So I did a wrapper around std::aligned_storage, and everything seemed to be working fine, but then address sanitizer stated, that I had a bunch of "use after free" cases with that aligned storage. I started digging up the std library implementation of the optional and found out about the std::launder. I slapped that thing to my optional, and it magically fixed those uses after free. Can you clear that out for me, please? The cppref article about std::launder didn't help at all
The raw strings shouldn't be necessary. JSON defines member names as valid JSON strings, so that is utf8 with only a few escapes that are needed(values
I’m puzzled by why I would want to specify configuration that is known at compile time in a different language. I suspect there is a good reason, but I haven’t yet found a case myself where I wasn’t better off factoring out a configuration source file in the language of the code it was configuring. What am I missing here?
It can reduce boilerplate and increase interoperability with other systems and languages. If the configuration is in JSON, it can more easily be generated or manipulated by other, automatic tools than source code. Usually you break out configuration like this when it becomes big enough that you don't enjoy doing it by hand.
I was thinking about config/**.ini files just as you mentioned configuration files. Nice
Why don't you simply escape backslashes and double quotes and include your string constants into ordinary double quotes? How do you handle unicode characters?
Great stuff, Jason!
So what is the use case for this? Am I correct in assuming it's just to incorporate a local JSON file into a C++ application by creating a class that has all it's data? So where would this be useful? Don't the majority of applications consume JSON at runtime? Possibly you have a web service that hits an API endpoint and gets load of data. That JSON has to be parsed at runtime.
What you can do is maybe create a structure that would hold easily that JSON (somehow) but creating this data structure for something you have locally... not seeing how useful that is to the majority of people.
If you have a massive JSON for configuration consider changing to SQLite or something.
Maybe I'm missing something here....
It's called "cross training." Runners have to also weight lift if they want to become better runners. This is true of C++ as well. You sharpen your C++ by exposing yourself to other concepts outside of the language.
@jason: why the *_impl.hpp? Is there a reason against putting the implementation directly in the *.cpp file?
@ok I see! So for the compile time checks, you would need to include the *_impl.hpp, and for the runtime access (with zero overhead) you just need the *.hpp.
@ok, thanks for the explanation!
A day early! I almost thought I'd gotten the day of the week wrong!
Interesting tool though, thank you!
I think that's two episodes in a row now on a Sunday. Lol hopefully Jason is ok or maybe this is a permanent change
Compile time json converter is nice. But in the real world, the json files are read by the application during start up and they are converted to classes.
Normally, servers are brought up much ahead of actual business time. In that case, what advantage does this bring?
I write simulators. High-fidelity simulators can take a _looooong_ time to start up due to heavy configuration, even for scenarios that might run in less time than they took to set up. I could easily see this being used to pre-compile scenario configurations as shared libraries and load them using dlopen. It would slow down scenario development, but scenarios are usually run far more often than they are changed and tested. It would also be easy enough to provide a "hot load" option that uses the JSON directly and sacrifices startup time for last-minute changes and scenario development.
I can't compile it unfortunately
Please open an issue on the project if you'd like me to look into it.
What’s with all the speed comments? He’s trying to be clear and articulate.
I don't understand those comments either. Seems fine to me
It's funny that they are appearing now. He's always used this pace in his videos, and I don't ever recall comments about it. I like to set the speed to 1.5, but it never occurred to me to complain about it. His style works great and youtube features can easily adjust the pace to each listener's preferences.
As a foreign viewer, I particularly appreciate how Jason speaks, I can understand what he says without reading subtitles. Don't change anything Jason !
Ha! very nice! 👍👍👍
For those of you that don't understand why this might be useful, you don't work with a resource constrained system that would clearly benefit from this. This video is not for you unless you want to play around with the techniques used or learn how to use them better. Jason mentions at least two examples where something like this could be useful.
Well I can make a configiguration as an .h files with a set of #define instead of this Json parser and it will be much faster to compile.
Why do you use the ugly include guard technique from 1978 instead of #pragma once?
@ok , it is de facto standard, I don't know a single compiler that doesn't support it (including the embedded ones).
@ok, it does because what you suggested could be an issue is actually not.
@ok, those compilers will also not support C++17/20/23, but for some reason you didn't say this JSON library is at fault by using these modern standards. Supporting shit compilers requires writing shit code, which, luckily, is not the scope of this channel.
@ok, I challenge you to find an example of a compiler that supports C++17 and doesn't support pragma once. I very seriously doubt one exists, and I don't understand why you're being so dense about it.
@ok, and more importantly, you call it a minor stylistic decision, but I call it proliferation and perpetuation of bad coding practice. Obviously, you've never hunted down a bug caused by clashing include guards, so it is you who has little experience.
Why do you slow down your videos? Feels like you intentionally set it to 0.5X
I'm one of those people who set most vids on UA-cam at 2x speed. You aren't an especially slow speaker.
A noob here, why is this necessary? Looks like a hassle.
nlohmann JSON library is the worst one I've tried. It is incredibly, ridiculously slow. Although the API is nice, much better than RapidJSON.
1.5x speed makes you sound like a human. 2x at least to get through this. Stop slowing down your videos.
Set speed to 1.25. Thank me later
I watch at 1.75 :), always
2x all of this series
1.5x for me, when I watch now at normal speed it sounds to me like he's had a stroke.
Lol
This looks very ugly tbh.
That's what she said.