
The documentation in http://boost.org/more/separate_compilation.html states that: these headers fix the ABI to the default used by the compiler, and if the user attempts to compile the source with any other setting then they will get compiler errors if there are any conflicts. If these headers really fix the ABI to the compiler's *default*, is there any point in creating all these libraries with special mangled names? Does the documentation really mean to say the headers fix the ABI to the settings with which we build the Boost binaries (or something like that)? Or have I misunderstood this whole thing? Thanks in advance, -- Dave Abrahams Boost Consulting www.boost-consulting.com

David Abrahams wrote:
The documentation in http://boost.org/more/separate_compilation.html states that:
these headers fix the ABI to the default used by the compiler, and if the user attempts to compile the source with any other setting then they will get compiler errors if there are any conflicts.
If these headers really fix the ABI to the compiler's *default*, is there any point in creating all these libraries with special mangled names? Does the documentation really mean to say the headers fix the ABI to the settings with which we build the Boost binaries (or something like that)? Or have I misunderstood this whole thing?
What I was trying to say (perhaps not very well) was: * If you're using the compiler default settings these headers have no effect. * If you're not using the default settings, and the library doesn't use these headers you get hard to track down binary compatibitity problems. *If you're not using the defaults, and the library does use these headers, then the ABI for the library gets forced to match the compilers default settings - the same setting we use to build the library with - and everything should just plain work. John.
participants (2)
-
David Abrahams
-
John Maddock