Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON for Modern C++

github.com

Post reply on HN
Print view View original

91–100 of 125 posts

Re: JSON for Modern C++

#91

Post by umvi »

kyberias wrote: post #20

I don't understand the JSON obsession. JSON as any other file format should be a small detail in any application and require very little plumbing code. In every application, any dependency to JSON should be minimized, contained and preferably eliminated.

Well I work on embedded systems that have embedded webservers (think your router's webpage). And what data format is easiest to work with when dealing with webpages and browsers? JSON.

Hence, our embedded C++ backend can now easily accommodate and return JSON to the front end using this library.

Plus, what data format do you propose for things like configuration files, etc? No matter what format you choose, you are going to need a parser of that format for C/C++.

Re: JSON for Modern C++

#92

Post by umvi »

Teknoman117 wrote: post #16

My only mild complaint with this particular JSON library is that it's fairly easy to shoot yourself in the foot with the compile times if you don't explicitly ensure that you use the json_fwd.hpp header in your headers.

Could you elaborate on how to speed up compile times? We use this library extensively and I've never heard of "json_fwd.hpp" until now.

Re: JSON for Modern C++

#93

Post by umvi »

omouse wrote: post #39

I'm wondering what the difference between this and json-cpp https://github.com/open-source-parsers/jsoncpp is. They look like they provide the same functionality, albeit this looks more "modern C++ style"?

nlohmann's is super nice. You can set a json object equal to a map or vector and it will automatically understand and do it. I doubt you can do that with jsoncpp.

Re: JSON for Modern C++

#94

Post by umvi »

baltbalt wrote: post #61

I don't understand those single header libraries. Anyone writing code in c or c++ knows how to link a library. It's really annoying when writing code for a platform with limited ram.

Unfortunately template-heavy libraries have to be header-only; otherwise the preprocessor doesn't know which flavors of the template you want to use.

Re: JSON for Modern C++

#95

Post by CoolGuySteve »

Betelgeuse90 wrote: post #33
jstimpfle wrote: post #28

Earlier quoted context omitted.

I tried to suppress the urge to release my frustration, but seeing that the only slightly critical comment in this thread is the downvoted one let me forget my good intentions. WTF. 10s of thousands of line of code, > 10K lines in include files (yay compile times!) for a task that should be only a side concern and should be straightforward to implement. JSON has how many? 2? data types, and writing super efficient pa…

Recently had a discussion with a colleague about JSON in C++. It's actually a big issue, because reflection isn't really supported in C++. It's not just a blocker for parsing objects as JSON, it's a fundamental limitation for being able to map objects to any kind of format in a general fashion without creating initializers for every object. I actually have no idea what kind of black magic they're doing to achieve thi…

I think worries about reflection are overthinking the problem for the most part.

This has carried me for 99% of all use cases along with a try/catch that barfs and an array specialization that makes a vector:

template T get(const char* key) { return boost::lexical_cast( json.GetObject(key) ); }

The reality is that if I see some value of a type I wasn't expecting, something probably went wrong or changed in the protocol anyways.

Re: JSON for Modern C++

#96

Post by snagglegaggle »

umvi wrote: post #91
kyberias wrote: post #20

I don't understand the JSON obsession. JSON as any other file format should be a small detail in any application and require very little plumbing code. In every application, any dependency to JSON should be minimized, contained and preferably eliminated.

Well I work on embedded systems that have embedded webservers (think your router's webpage). And what data format is easiest to work with when dealing with webpages and browsers? JSON. Hence, our embedded C++ backend can now easily accommodate and return JSON to the front end using this library. Plus, what data format do you propose for things like configuration files, etc? No matter what format you choose, you are g…

I think TOML is better, maybe with some modifications. I dislike that it has a person's name in it though; maybe we retcon it to Text Object Markup Language.

TOML has inline and multiline forms for most objects.

Re: JSON for Modern C++

#97

Post by CoolGuySteve »

devwastaken wrote: post #82
kyberias wrote: post #20

I don't understand the JSON obsession. JSON as any other file format should be a small detail in any application and require very little plumbing code. In every application, any dependency to JSON should be minimized, contained and preferably eliminated.

Json is easier for humans to read and modify, and it's more straightforward to work with in languages like python where you don't have to declare types. Json c++ implimentation is large probably because of trying to provide one library that does all the dynamic things json can do, but in a static language. It also has to be safe to parse, so there's that.

For config files at least, I've moved entirely to ini format. Python's configparser is handy for machine generating complicated configs and the nesting/list support in JSON adds way more complexity than I need compared to just using comma separated lists as values.

This is my entire ini parser for making a std::map. I cast/parse the values at the use site:

    std::regex section_test("\\[(.*?)\\]");                                                                             
    std::regex value_test("([\\w\\.]+)\\s*=\\s*([^\\+]+(?!\\+{3}))");

    while(-1 != getline((char**)&buf, &len, file))                                                                      
    {                                                                                                                   
        std::string line(buf);                                                                                          
        trim(line);                                                                                                     
        if(!line.size() || line[0] == '#') continue;

        std::smatch match;                                                                                              
        if(std::regex_search(line, match, section_test))                                                                
            current_section = match[1].str();                                                                           
        else if(std::regex_search(line, match, value_test))                                                             
        {                                                                                                               
            std::string key(match[1].str());                                                                            
            std::string value(match[2].str());                                                                          
            info("INIReader: %s::%s = %s\n",                                                                            
                    current_section.c_str(), key.c_str(), value.c_str());                                               
            config[current_section][key] = value;                                                                       
        }                                                                                                               
    }

Re: JSON for Modern C++

#98

Post by mristin »

omouse wrote: post #42
Betelgeuse90 wrote: post #33

Earlier quoted context omitted.

Recently had a discussion with a colleague about JSON in C++. It's actually a big issue, because reflection isn't really supported in C++. It's not just a blocker for parsing objects as JSON, it's a fundamental limitation for being able to map objects to any kind of format in a general fashion without creating initializers for every object. I actually have no idea what kind of black magic they're doing to achieve thi…

Reflection isn't required; keys in JSON are strings, and there are basic data types that are supported (strings, numbers, booleans, arrays, and dictionaries which are more of the same). What's wrong with writing "initializers" which are serializers/deserializers? If you're looking for automatic file format to C++ class object, why settle for JSON (whether it's this library or JSONCpp) why not use Thrift or Protocol B…

See also Mapry [0], a code generator we particularly made for JSON.

[0] https://github.com/Parquery/mapry

Re: JSON for Modern C++

#99

Post by umvi »

CoolGuySteve wrote: post #97
devwastaken wrote: post #82

Earlier quoted context omitted.

Json is easier for humans to read and modify, and it's more straightforward to work with in languages like python where you don't have to declare types. Json c++ implimentation is large probably because of trying to provide one library that does all the dynamic things json can do, but in a static language. It also has to be safe to parse, so there's that.

For config files at least, I've moved entirely to ini format. Python's configparser is handy for machine generating complicated configs and the nesting/list support in JSON adds way more complexity than I need compared to just using comma separated lists as values. This is my entire ini parser for making a std::map . I cast/parse the values at the use site: std::regex section_test("\\[(.*?)\\]"); std::regex value_tes…

This has to pull in std::regex though which is pretty heavy

Re: JSON for Modern C++

#100

Post by CoolGuySteve »

umvi wrote: post #99
CoolGuySteve wrote: post #97

Earlier quoted context omitted.

For config files at least, I've moved entirely to ini format. Python's configparser is handy for machine generating complicated configs and the nesting/list support in JSON adds way more complexity than I need compared to just using comma separated lists as values. This is my entire ini parser for making a std::map . I cast/parse the values at the use site: std::regex section_test("\\[(.*?)\\]"); std::regex value_tes…

This has to pull in std::regex though which is pretty heavy

std::regex is part of c++11 anyways so there's nothing to integrate with your build system.

I put this code in a standalone cpp file so that it compiles to its own object in parallel with the rest of the system. I've never had issues with it with regards to build times.

Post reply on HN