"Robert Ramey"
I was out whacking weeds today and was thinking about this.
I'm going to guess that the unseen code in Bill example has a number of BOOST_CLASS_EXPORT macros. The current version will instanciate code for every combination of exported type and included archive class. At startup there will be three times as much code invoked to "register" these combinations.
During in the course of serialization, there are look ups into the tables built at init time. These are stl sets, map and the like. Its possible that the fact this combination of compiler/library implementation consumes a disproportionate time under these circumstances. I would guess that one would need to use a profiler to get more information on this.
Currently code is instantiate for each combination of exported type and included archive. Question for Dave: Is this the same in the new improved version of export (1.35) or does the new one only instantiate code for each archive actually used with an << or & operator? - Just asking.
It does exactly what your old code did. Having it just instantiate the code for the type/archive combinations used would be _so_ much easier to implement. Personally, I don't understand why you'd want it to work the way it does, but I figured it was hard enough to do that you must've been sure that's what you wanted, and eliminating the ordering requirement looked like a big enough battle. -- Dave Abrahams Boost Consulting www.boost-consulting.com