Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to turn this into a shared library? #420

Closed
RPGillespie6 opened this issue Jan 6, 2017 · 8 comments
Closed

Is it possible to turn this into a shared library? #420

RPGillespie6 opened this issue Jan 6, 2017 · 8 comments
Labels
kind: enhancement/improvement solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope)

Comments

@RPGillespie6
Copy link

I'm really liking this library.

However, my use case is in an embedded ARM environment with limited flash storage. Every time I include this library in an app, it increases the size of the app by ~50KB after stripping.

Is there a way to turn this .hpp into a .so so that I don't have to pay 50KB per app? I was thinking I could just include it into a .cpp file and turn that into a .so, but then I still need a header file that exposes the public APIs.

@nlohmann
Copy link
Owner

nlohmann commented Jan 6, 2017

As the library uses a lot of templates, a shared library would need to restrict the possible types. For instance, we can parse anything with an iterator range - if we would want a shared library, we would need to choose, for instance, std::string and leave char * out.

I'm not saying it would be impossible, but I think it would mean a lot of (manual) work.

Does anyone has an idea whether tools for this exist?

@nlohmann nlohmann added the state: help needed the issue needs help to proceed label Jan 6, 2017
@RPGillespie6
Copy link
Author

BTW - It's not a big deal. I can live with +50KB per app - I was just curious if it would be a simple thing to do, and if the answer is "no", then feel free to close this issue.

@boguscoder
Copy link

@nlohmann There's no need to make shared library with C api surface, its totally fine to pass std::string cross dll/so - boundaries but user have to understand all the implications:

  1. Both app and .json shared library must use same and dynamic runtime/stl, as long as things like gnustl_shared.so are available for platform in question it will not be a problem

  2. Linking app and .json shared library with own copies of runtime/stl will work but will cause havoc that may be hard to debug, std::strings allocated by one rt will end up being deallocated in another ..

@nlohmann
Copy link
Owner

@boguscoder I do not understand - right now, there is no library (neither shared nor static), but only a header.

@tksatware
Copy link

@RPGillespie6 there is not overhead if you don't use any functions. It is just a header. Actual binary code only appears when objects are used.

@JoveToo
Copy link

JoveToo commented Mar 20, 2017

@RPGillespie6 I don't know how your code is currently structured or if those different apps have anything in common but if you can split your current object headers into object.h (containing only your class definition), object.cpp (class methods), object_serialize.h (containing only the to_json and from_json function declarations) and object_serialize.ccp (containing the function bodies) and only include json.hpp in the _serialize.cpp files, you can link all object_serialize.cpp's into a single shared library.

You would need a forward declaration of the json class to make the friend function declarations in object.h and the to_json and from_json headers in object_serialize.h compile but otherwise, all json.hpp code would be split off in a separate shared library. If a forward declaration is not enough, you can include json.hpp but take care not to actually include anything but function declarations (without bodies).

Of course, this would only actually win you significant code size if all of those apps also share objects, if not, I doubt the winnings will be substantial.

@nlohmann nlohmann added the state: please discuss please discuss the issue or vote for your favorite option label Jun 5, 2017
@nlohmann
Copy link
Owner

nlohmann commented Jun 5, 2017

I'm still not sure what to do here. I am currently leaning to closing this issue.

@Type1J
Copy link
Contributor

Type1J commented Jun 5, 2017

@JoveToo described a good solution. I don't think that there is a better one availible, and it's not in the scope of this library, only its usage. Therefore, this issue should be closed.

@nlohmann nlohmann added solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope) and removed state: help needed the issue needs help to proceed state: please discuss please discuss the issue or vote for your favorite option labels Jun 6, 2017
@nlohmann nlohmann closed this as completed Jun 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement/improvement solution: wontfix the issue will not be fixed (either it is impossible or deemed out of scope)
Projects
None yet
Development

No branches or pull requests

6 participants