Robert Ramey wrote:
Are you sure you're building in release mode?
Yes of course. Is that expected to make a difference? Reading from `force_include.hpp`, even Release mode wouldn't escape from this (see below) I dug into the problem a little bit more. I replaced `force_include.hpp` with the following two lines and then actually recompiled boost::serialization #define BOOST_DLLEXPORT #define BOOST_USED The code bloat is gone (as shown by `dumpbin /exports`, yes, actually by 8MB), *and* the resulting program actually compiles and runs fine (sample program at: http://boost.codepad.org/f9LodmfD **). I tested again at MSVC2010 at both Release|x64 and Release|Win32. This seems to be a rather intrusive hack that seems to have become outdated with MSVC2010 (haven't tested with MSVC2005 and MSVC2008 yet. It's installed on another machine). Right now, `force_include.hpp` reads this: #if defined(BOOST_HAS_DECLSPEC) && !defined(__COMO__) // ... # define BOOST_DLLEXPORT __declspec(dllexport) This means we are unconditionally doing this explosive exports for all MS platforms. Even Release mode cannot optimize away these explicitly marked DLL exports. Should we at least have an option to turn off this very intrusive workaround? Right now my only option is to patch `force_include.hpp` manually. There might be some people that actually need the hack, but for some of us who's dug into it and actually confirmed it's not needed, it would be nice to be able to turn that off since the bloat introduced is definitely non-trivial. ** Of course I don't mean this particular sample program generates 8MB of export symbols. This is only to show what I mean by "it compiles and runs." The actual program that resulted from boost::serialization's 8MB bloat contained 100+ "exported" classes serialized through base pointers. The specs is quite close to what I showed in the sample program. ** That doesn't seem to play well with CodePad's boost. Oh well. Best regards, Chris Yuen