From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2007-05-18 17:09:01
On Friday 18 May 2007 22:39:49 Michael Caisse wrote:
> Ulrich Eckhardt wrote:
> > Doing that would effectively declare all code inline, possibly causing
> > massive code bloat and compile time increase. I don't think its a good
> > idea.
> > Attached is a file. Copy it to the boost/signals folder and include it
> > from exactly one translation unit of your program. All it does is make an
> > on-demand compiled, statically linked library.
> > BTW: I have the same for Boost.Thread here, though it requires a patch to
> > one file, and intend to attempt the same for other libraries requiring
> > linking, too.
> > HTH
> > Uli
> Please excuse what must be my ignorance. Why are people so opposed to using
> the linker and static libraries?
I'm not opposed to it, but it presents additional overhead. Consider my case,
I'm developing STLport and using it, so that makes one stable version and a
development version and for each a debug, a release and a diagnostic build.
Then, I might have the same case with Boost. Further, I have a handful of
targets/compilers. Lastly, I might be playing with different compiler
settings. All these variations are multipliers(!!!) for the number of e.g.
Boost libraries I would have to compile, and that is enough reason for me to
use above way of linking.
As far as your specific mentioning of static libraries is concerned, I'd say
this method has the advantage of automatically adapting to the compile
environment. When put into a seldom-changed file, the recompilation overhead
BTW: I also use compiled DLLs in released binaries. However, compiling
in-place is way easier if you have nonstandard variations or just want to
hack a quick example on a computer that doesnt't have any libraries
installed. All ways have their advantages and disadvantages, this one just
offers another choice.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk