You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think this would be fare more useful as a header only library. I'm down for sending a PR with the change if you are.
And as I wrote:
Good idea! But I think it would be more useful if there would be a script that reads the source files json.cc and json.h and creates a header-only version. That way, both approaches can be followed at the same time.
It can improve compile time when precompiled headers are used and allows easy include only usage. The cpp file always has to be supplied to the compiler (which is mostly done by build tools that assume everything in one root) and therefore encourages adding the source directly in projects instead of just pulling them from a central include path.
Unfortunatly the cpp world has no ultimate solution to dependencies, packaging, etc. so I don't know if this is an advantage for others.
I've seen it and it seems pretty cool, but I don't want to rely on proprietary tools. I couldn't find a statement about escrow or plans for worst case.
Should we really push the generated header only version to the repository? It's a generated file similar to a binary and should be hosted somewhere else.
I thought about it and thought the way Catch are doing it is reasonable. In the end, creating the header requires tools such as cat and sed. While they may be standard on some machines, they are not for Windows. Once the code is reasonably stable, one could think about using GitHub's release feature.
I think a release on Github from time to time is the best solution right now. It's just slightly more work compared to pushing the header file to git and it keeps the repository clean.
If we want this automated, we could also just run the header generation on a external server and serve it over HTTPS (or use the Github API to create releases).
Sorry for the late reply. Unfortunately just copying header and source together won't be enough. While free functions could be inlined, the member functions that are defined outside of their class declarations can't.
From my point of view there are only upsides for developing the library completely header only but I understand that it might also be a matter of taste.
As I have no experience in creating a header-only version, I assumed that copying the sources would be enough. Can you give me more insights why this is not sufficient or point me to sources that explain how to do this properly?
👍 for header-only version. I'm very happy with this library but I had to do my own temporary patching (inlining) so that I could use it in my own header-only libraries.
Activity
hrobeers commentedon Jan 6, 2015
Or people can just include the cpp file.
I don't really see the advantage of making it header only.
PaulFreund commentedon Jan 8, 2015
It can improve compile time when precompiled headers are used and allows easy include only usage. The cpp file always has to be supplied to the compiler (which is mostly done by build tools that assume everything in one root) and therefore encourages adding the source directly in projects instead of just pulling them from a central include path.
Unfortunatly the cpp world has no ultimate solution to dependencies, packaging, etc. so I don't know if this is an advantage for others.
daminetreg commentedon Jan 8, 2015
Have you already seen biicode ? They are really active in bringing a dependency solution for C++.
PaulFreund commentedon Jan 8, 2015
I've seen it and it seems pretty cool, but I don't want to rely on proprietary tools. I couldn't find a statement about escrow or plans for worst case.
created a header-only version (see issue #16)
nlohmann commentedon Jan 9, 2015
@PaulFreund - could you check if the file
header_only/json.hsuits your needs?Teemperor commentedon Jan 9, 2015
Should we really push the generated header only version to the repository? It's a generated file similar to a binary and should be hosted somewhere else.
nlohmann commentedon Jan 9, 2015
I thought about it and thought the way Catch are doing it is reasonable. In the end, creating the header requires tools such as
catandsed. While they may be standard on some machines, they are not for Windows. Once the code is reasonably stable, one could think about using GitHub's release feature.@Teemperor, what do you think?
Teemperor commentedon Jan 10, 2015
I think a release on Github from time to time is the best solution right now. It's just slightly more work compared to pushing the header file to git and it keeps the repository clean.
If we want this automated, we could also just run the header generation on a external server and serve it over HTTPS (or use the Github API to create releases).
nlohmann commentedon Jan 11, 2015
Apart from the issue of how to publish the header-only version, I think we are done here.
PaulFreund commentedon Jan 11, 2015
Sorry for the late reply. Unfortunately just copying header and source together won't be enough. While free functions could be inlined, the member functions that are defined outside of their class declarations can't.
From my point of view there are only upsides for developing the library completely header only but I understand that it might also be a matter of taste.
nlohmann commentedon Jan 11, 2015
Thanks @PaulFreund for your reply.
As I have no experience in creating a header-only version, I assumed that copying the sources would be enough. Can you give me more insights why this is not sufficient or point me to sources that explain how to do this properly?
Zoadian commentedon Jan 16, 2015
you'll get duplicated symbols if you include it more than once
nlohmann commentedon Jan 21, 2015
You are right. I did not check for a case where the header is included in several files. :-(
danpolanco commentedon Feb 4, 2015
👍 for header only version.
fixed duplicate symbols errors on header-only version. issue nlohmann#16
cdaylward commentedon Feb 9, 2015
👍 for header-only version. I'm very happy with this library but I had to do my own temporary patching (inlining) so that I could use it in my own header-only libraries.
nlohmann commentedon Feb 18, 2015
Fixed in latest commit: the class is now header-only.
danpolanco commentedon Feb 19, 2015
👏
Merge pull request nlohmann#16 from nlohmann/develop
fix: update crossmap and natives to b3095(nlohmann#16)