From: Norbert Unterberg (nunterberg_at_[hidden])
Date: 2007-12-21 16:21:10
I am a Windows developer who aleady used boost, and UI think I might share my
experience. From my point of view, I do not understand the discussion about the
default build type. For serious windows developers, there is no default.
John Maddock wrote:
> It's probably more accurate to say that it's an MSVC'ism: folks using msvc
> really don't like distributing dll's with their applications. The
> complaints to the main Boost mailing list to "please make static linking the
> default" were really quite persistent until I changed.
From my point of view, I do not understand the discussion about the default
build type. For serious windows developers, there is no default.
Whenever you create a new project in visual studio, you are asked the questino
about using static or dynamic linked runtime.
Whatever you select, you need to think about it, and both have serious
consequences to your application and the way you distribute it:
Static linking means you can just distribute one executable, and you are done.
This is nice for small projects, and for tools and utilites you distribute. But
it usually makes your application much bigger than it needs to be.
But: As soon as your application is split into more than one module (multible
EXE files or DLL), you want and need the code reuse. And then you are forced
(not really, but you'd better do it) to switch to dynamic runtime. Otherwise you
need to be very careful with object/memorys ownership, usage of C++ objects and
So whenever I get a third party library to use in my apps, I do not ask how it
is built. I just expect at least the mentioned four variants: Debug/Relase vs
Dynamic/static linkage. When I rebuild without special options (like --static or
--debug) I expect all four variants to be built. And if that is too much, I
would expect that I have to chose explicitly which one to build.
There is another variant that needs to be considered: statically link to a boost
library which then links dynamically to the C/C++ runtime. That way you could
hide boost within your application/dll, while still be able to use your
compiler*s DLL runtime which might already be on the custome's pc anyway.
BTW, all these variants, if built, should be automatically selected with
auto-link, of course.
> BTW, while it is technically possible to use the one of the release runtimes
> in a debug build with msvc, almost no one does that - the IDE makes it
> rather tricky to do, and in my experience it often causes hard to track down
> issues - not least because it confounds the expectations of any other
> non-Boost libraries that autolink.
Under windows, the difference between debug and release builds is essential and
important. You simply can not run a debug application with a release boost
library linking to a debug CRT. The program would most likely fail with very
strange errors. Think for instance of iterator debuggin support in the MS
> IMO the minimum for msvc is the 4 variants that match the 4 runtimes shipped
> with vc8.
Well, or 6 variants, as I said above.
In our applicatinos, boost is still considered more of a utility part of the
application than a runtime library, so it should be possible to do a stati link
to boost while linking the dll runtime. At least bost build system should be
able to build these libs if required.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk