add release information in static function

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.

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.

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        
}

@whackashoe

@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.

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

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

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

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.

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 :)

🚧 started working on #397

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?

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).

The version number is already mentioned in line 3 of the header.
I added the name and copyright, because it could facilitate other integrations.
About a year range: I remember once reading a GNU document which stated that a range is required.
The URL should be "the" URL of the project. Right now, it is the Github page, but it may change to some dedicated page in the future.

If the function is going to return more than basic version information for the library, using a different name such as diagnostics(), info() or meta() might be a better idea. version()["copyright"] and the like don't quite make sense, and version()["version"] sounds repetitive.

@erengy

@erengy This is a valid point, and I like the name meta() for it.

FYI: Renamed the function to meta() in dd45ba6

🔀 merge branch 'feature/release_information' into develop #397

Navigation Menu

Repository navigation

add release information in static function #397

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

add release information in static function #397

Description

Activity

erengy commented on Dec 19, 2016

whackashoe commented on Dec 20, 2016

nlohmann commented on Dec 20, 2016

whackashoe commented on Dec 20, 2016

nlohmann commented on Dec 21, 2016

whackashoe commented on Dec 21, 2016

nlohmann commented on Dec 21, 2016

whackashoe commented on Dec 21, 2016

nlohmann commented on Dec 30, 2016

whackashoe commented on Dec 30, 2016

nlohmann commented on Dec 31, 2016

erengy commented on Jan 2, 2017

nlohmann commented on Jan 2, 2017

nlohmann commented on Jan 8, 2017

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions