|
Boost : |
From: Edward Diener (eldiener_at_[hidden])
Date: 2008-07-11 17:02:51
I think it is an error when an end-user uses a Boost library which may
need a separate DLL built, never uses a function/class which is
implemented in that separate DLL, and yet the Boost header files for
that library bring in autolinking. Is this considered an error in the
development of a Boost library ?
What is invariably happening when this situation occurs is that a header
file which has autolinking code ( #pragma comment(lib,"somelib") in VC++
for example ) is included for functions/classes which are not in the
autolinked library at all. This is because the Boost developer has not
placed all the autolinked functionality for a particular library in its
own header file, preferring instead to place declarations in logically
related header files. While the latter is understandable as far as
organization of a library is concerned it destroys the ability of that
library to enforce autolinking only when the end-user requires it.
Despite the fact that library developers, of Boost libraries which are
not completely header only, go for orthogonality when creating their
header files I would like to see things changed so that using a library
which does not require the built library to be linked in when using
functionality of that library does not being in autolinking. I realize
that there are macros of the BOOST_SOMELIB_NO_LIB around to turn off
autolinking but this places a burden on the end user which should not be
there.
I was recently using the date/time library for the first time, used
functionality which I was pretty sure was not in the built library based
on the documentation, yet autolinking code was brought in to force me as
an end-user to specify the location of the import library. When I
defined BOOST_DATE_TIME_NO_LIB in my project settings, everything linked
fine without specifying the import library, so obviously the DLL was not
needed. Nobody wants to distribute a shared library with their code when
it is unnecessary.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk