-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
Comments
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, 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? |
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. |
@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:
|
@boguscoder I do not understand - right now, there is no library (neither shared nor static), but only a header. |
@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. |
@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. |
I'm still not sure what to do here. I am currently leaning to closing this issue. |
@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. |
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.The text was updated successfully, but these errors were encountered: