> The main problem with shared_ptr 1.30.x and below is that the single- and > multithreaded versions are incompatible. The CVS version is now binary > compatible on Windows, so 1.31 will "work" across different threading > models; still, the correct default for Borland should probably be to do a > multithreaded build. > > By the way, this can't be fixed with prefix/suffix headers.
Agreed, no-one is trying to fix that - threaded and non-threaded builds use different run time libraries for both the Microsoft and Borland compilers - mixing code that was built with threading turned on with code where it is turned off will *always* cause ODR violations, even if you're not using boost :-) > > but by default the libraries are all built using > > the default compiler option for the tool. The inlined (header-only) > > library are only tested against that default set, so why not enforce > > that default set for all boost libraries? If an individual library > > author then wants to enforce another set (different alignment or > > something) for optimisation purposes, then let then over-ride the > > defaults, > > But I don't want to enforce a set. I want (for example) shared_ptr to use > whatever set the user has specified and not to override his settings. Which causes no end of issues for libraries with separate source, unless we abandon having a build system altogether and just tell people to "build everything yourself". To put this in perspective for C++ Builder the following options effect the ABI: -b (on or off - effect emum sizes) -Vx (on or off - empty members) -Ve (on or off - empty base classes) -aX (alignment - 5 options). -pX (Calling convention - 4 options) -Vmx (member pointer size and layout - 5 options) -VC (on or off, changes name mangling) -Vl (on or off, changes struct layout). In addition, there are a whole bunch of separate runtime libraries - 4 C libraries, plus 2 STLPort versions on top (so 8 combinations). And that's not counting the optional diagnostic libraries or the optional use of Rogue Waves STL. So assuming we build libraries for the 8 runtime variants we can't control, that still leaves 2*2*2*5*4*5*2*2=3200!!! ABI options for each runtime variant. Seriously we need to get a handle on this where we can - and please don't forget users can always turn this off if they want to handle the ABI themselves. One final point - there was a reason that I moved regex to use automatic library selection and ABI fixing - without it I was getting a tonne of support requests along the lines of "Your library doesn't work, it just crashes when I call anything", which almost always turned out to be caused by ODR violations (either the user had changed an ABI option, or had linked to the wrong runtime-library-build variant), these basically stopped overnight once I modified my code to stop those (this was all in pre-boost days BTW). Convinced yet? John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost