fix for 3732

[luistung]

fix #3732 , add explicit instantiation for nlohmann::basic_json<nlohmann::ordered_map>

---

Pull request checklist

Read the Contribution Guidelines for detailed information.

• [x] Changes are described in the pull request, or an existing issue is referenced.
• [x] The test suite compiles and runs without error.
• [x] Code coverage is 100%. Test cases can be added by editing the test suite.
• [x] The source code is amalgamated; that is, after making changes to the sources in the include/nlohmann directory, run make amalgamate to create the single-header files single_include/nlohmann/json.hpp and single_include/nlohmann/json_fwd.hpp. The whole process is described here.

Please don't

• The C++11 support varies between different compilers and versions. Please note the list of supported compilers. Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with #ifdefs or other means.
• Specifically, I am aware of compilation problems with Microsoft Visual Studio (there even is an issue label for these kind of bugs). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
• Please refrain from proposing changes that would break JSON conformance. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
• Please do not open pull requests that address multiple issues.

[falbrechtskirchinger]

As I've stated in the bug report, I don't think that's an acceptable solution. This can be fixed without penalizing every user who doesn't use ordered_json.

[luistung]

As I've stated in the bug report, I don't think that's an acceptable solution. This can be fixed without penalizing every user who doesn't use ordered_json.

Does explicit instantiation hurt others?

[falbrechtskirchinger]

It hurts everyone's compilation speed. And there is a solution that doesn't.

Also, I'd like to understand this problem better to make sure we're not masking a deeper issue. That's one of the reasons I haven't submitted a PR myself yet.

[coveralls]

Coverage decreased (-0.3%) to 99.67% when pulling c67e101b77c0e3f4bc6f1df91141aac4c674ac50 on luistung:issue3732 into 58bd97e2b101c7ba0fc55e81be42498bcd932fd7 on nlohmann:develop.

[luistung]

It hurts everyone's compilation speed. And there is a solution that doesn't.

Also, I'd like to understand this problem better to make sure we're not masking a deeper issue. That's one of the reasons I haven't submitted a PR myself yet.

I got it. But you reminded me another thing. The nlohmann::json has been instantiated by default due to the declaretion of inline nlohmann::json operator "" _json(const char* s, std::size_t n). How can user who does not use nlohmann::json get rid of the instantiation.

[falbrechtskirchinger]

True. This was also brought up here recently:

(...) And the template gets instantiated in every translation unit because of the _json UDL, even if you don't use any nlohmann function (although that can somewhat be mitigated with the _fwd header).

There's no way to disable the definition when including json.hpp.

[nlohmann]

Also, the CI is red.

[falbrechtskirchinger]

warning C4459: declaration of 'j' hides global declaration

I've fixed this issue in several PRs that have not been merged. I really should submit a separate PR.

(The noexcept unit test declares a global variable j that conflicts with parameters named j. Easily fixed by renaming the global.)