Re: [boost] Signals and slots requiring linkage

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 
is negligible.

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.

Uli