add release information in static function

[nlohmann]

To detect the version of the used library (both in case of support requests and also to detect the version in a binary), we should add a function that returns a version string and a UUID.

[erengy]

In my application's About dialog, third-party components are listed in the following manner:

Fugue Icons 3.4.5, json 2.0.9, libcurl 7.51.0, pugixml 1.7.0, utf8proc 1.3.0, zlib 1.2.8

It'd be nice if I could programmatically get the version number of this library too, rather than manually changing a hard-coded value after each update:

std::cout << "json " << nlohmann::json::version();  // json 2.0.9

I was planning to open an issue for this, so I'm happy to see that it's going to be in an upcoming release.

[whackashoe]

Some of these might be useful too

std::string get_platform()
{             
#ifdef _WIN32 
    return "win32";
#elif __linux__
    return "linux";
#elif __APPLE__
    return "apple";
#elif __unix__                                                                                            
    return "unix";
#else         
    return "unknown";
#endif        
}             
              
std::string get_compiler()
{             
#if defined(__clang__)
    return "clang";
#elif defined(__ICC) || defined(__INTEL_COMPILER)
    return "icc";
#elif defined(__GNUC__) || defined(__GNUG__)
    return "g++";
#elif defined(__HP_cc) || defined(__HP_aCC)
    return "hp"
#elif defined(__IBMC__) || defined(__IBMCPP__)
    return "ibmcpp";
#elif defined(_MSC_VER)
    return "vs";
#elif defined(__PGI)
    return "pgcpp";
#elif defined(__SUNPRO_C) || defined(__SUNPRO_CC)
    return "sunpro";
#else         
    return "unknown";
#endif        
}             
              
std::string get_cpp_version()
{             
#ifdef __cplusplus
    return std::to_string(__cplusplus);
#else         
    return "unknown";
#endif        
}             

[nlohmann]

@whackashoe I did not plan to provide such diagnostic information. I had a different goal: I would like to get a string into binaries using the library so that I can detect the library later on.

[whackashoe]

Ahh.. ok. I had thought what you meant above wrt for support requests it might be useful to be able to have some diagnostics.

[nlohmann]

For diagnostics, would not be cmake --system-information more helpful?

[whackashoe]

Not really, usually wont have the same info that the user is building their actual project with.

[nlohmann]

But I guess they may answer questions on the used compiler, version, and OS. At least I never had the need to get these details programmatically.

[whackashoe]

Afaik it just shows default, not necessarily what people are using. What I have seen in a few programs, take ffmpeg for example where it gives version, copyright, compiler + version _ os, flags... its full blown suite compared to json so I mean that might be overkill but meh.. a feature like this isn't really "stl" like, but might be helpful. I think the whole reason they included it was just for ease of reporting so sorta similar deal. Really a matter of taste of how much cruft you wanna include :)

[nlohmann]

I implemented a version() function which returns a JSON like this:

{
  "compiler": {
    "c++": "201103",
    "family": "clang",
    "version": 80000
  },
  "copyright": "(C) 2013-2016 Niels Lohmann",
  "name": "JSON for Modern C++",
  "platform": "apple",
  "url": "https://github.com/nlohmann/json",
  "version": {
    "major": 2,
    "minor": 0,
    "patch": 10,
    "string": "2.0.10"
  }
}

Any thoughts on this?

[whackashoe]

I recommend ripping the major/minor/patch out to constexprs and tossing them near the top so people could quickly see what version with just a quick opening of file.

name seems unnecessary.

url might be better name-suited to repo or something assuming the users of forked versions would change the url to reflect their mod. (very subjective, idk if I even agree with this statement- just off-the-cuff thought)

copyright year range isn't necessary, it's just a signal to others how long its been going on, however this is easily found in git history. Might make sense to just go w/ "author": "Niels Lohmann" so people could credit you easily without having to remove the (C) x-x bit or retype your name (the horror).