On 9/08/2019 21:09, Edward Diener wrote:
Unless a library uses different public/protected functionality based on the choice between boost::chrono or std::chrono there will be no API incompatibility for the library itself. As far as ABI incompatibility I discuss in the cxxd docs how a shared library can produce different versions based on the cxxd choice for a dual library. For header-only libraries, which is a good part of Boost, ABI incompatibility does not exist AFAICS, but maybe I am missing what you mean when you say that.
Even header-only libraries do need to consider ABI incompatibility for their consumers, even if not for themselves. It's not always safe to assume that a given library will always be consumed with identical settings, especially if it is separately consumed by an application and another library. Where the alternate types appear only in the signature of methods (method parameters), this is relatively harmless, as long as the library does not rely on singletons. Where the alternate types appear in return types and class definitions, however, it can be significantly more problematic, unless the library was written with this in mind and uses multiple implementations and namespacing appropriately. Which is often not the case, because it's a lot more work and/or code duplication.