Re: [Boost-users] header-only libraries
I'd like to use the program_options library, but am reluctant to require my users to build parts of Boost. Is there a strong reason that this library cannot be header-only?
You can build the necessary Boost CPP files as part of your own build.
Asio (which is header-only) offers the possibility for "optional separate compilation" by including some ".../impl/src.hpp" in a source file and defining either "BOOST_ASIO_SEPARATE_COMPILATION" or "BOOST_ASIO_DYN_LINK", which very nicely lets the user choose which one suits best for his needs. Is there a reason why this isn't done for other libs like program_options, regex, etc., or has it (at least sometimes) just not been done because nobody wanted to do this extra-work? It is a very frequently asked question if/why not there is a header-only version, and although it is sometimes really not possible to make it header-only, most libs should work that way. Furthermore, in my experience specially commercial projects are reluctant to use libraries that have to be shipped with the own product, whereas it is no problem as long as they are "hidden" inside the binary.. Of course there are some disadvantages as shown in the discussion on stackoverflow, but giving the user a choice where possible should hugely increase acceptance and usage of those libraries. Greetings, dib PS: I just tried it with program_options and at least with my programs on linux it works fine, don't know how it is on other platforms or if I was just lucky: copy the src-files from libs/program_options/src to the include/boost/program_options/impl and do it "the asio-way", including the source files in a separate .cpp in my projects.. works fine and no linking is required any more.
Furthermore, in my experience specially commercial projects are reluctant to use libraries that have to be shipped with the own product, whereas it is no problem as long as they are "hidden" inside the binary..
It seems that you're confusing static and dynamic libs. Some boost libraries need to be built -- but no one obligates to build them as dynamic libs.
Am 27.03.2013 15:36, schrieb Igor R:
Furthermore, in my experience specially commercial projects are reluctant to use libraries that have to be shipped with the own product, whereas it is no problem as long as they are "hidden" inside the binary..
It seems that you're confusing static and dynamic libs. Some boost libraries need to be built -- but no one obligates to build them as dynamic libs. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I am not sure if there are not still some compilers/linkers that do not support mixed linking of libraries (static and dynamic), which would bring the same problem again. Further, afaik, with static linking you won't have link-time-optimization and dead code removal (at least until boost has been compiled with the appropriate options, which it isn't by default) Anyway, you are right, most of the times it would be a possible solution to link statically. Still, asio offers this possibility and I am eager to know if there is a reason why no other library (e.g. program_options) does. If I find the time I would perhaps try the exercise to make a patch for one or the other lib, but want to avoid that afterwards somebody tells me that I could have saved the time because of some reason.. Greetings, dib
On Mar 27, 2013, at 12:00 PM, dib wrote:
Still, asio offers this possibility and I am eager to know if there is a reason why no other library (e.g. program_options) does.
If I find the time I would perhaps try the exercise to make a patch for one or the other lib, but want to avoid that afterwards somebody tells me that I could have saved the time because of some reason..
It's probably a matter of resources. And it's not just the effort needed to develop the code. Distinct build configurations like this that are not tested tend to bit rot. And the more such build configurations there are, the harder it becomes to test the various possibilities in combination.
I am not sure if there are not still some compilers/linkers that do not support mixed linking of libraries (static and dynamic)
Excuse my ignorance, what's this? How can one link a library both statically and dynamically?
Further, afaik, with static linking you won't have link-time-optimization and dead code removal (at least until boost has been compiled with the appropriate options, which it isn't by default)
Well, it's quite trivial to add something like cxxflags=/GL, so it doesn't seem to be an issue. OTOH, build times might grow significantly in a header-only version.
Still, asio offers this possibility
I believe, this's for historical reasons: before 1.44 asio was header only, since 1.44 there was added the separate compilation option.
participants (3)
-
dib -
Igor R -
Kim Barrett