Re: Potential project: Resolving boost::chrono conflicts with std::chrono

From: Gavin Lambert (boost_at_[hidden])
Date: 2019-08-11 23:44:51

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.