On 12/11/2015 06:26, Louis Dionne wrote:
(1) How can you guarantee ABI compatibility from one version of a library to the next? IIUC, ABI can be broken by merely changing the size or the layout of a type, so guaranteeing backwards ABI compatibility means freezing those things in time, right?
It's really hard to do this absolutely (since compiler settings can affect things as well), which is why it's rarely done. (But nice where possible.)
(2) Assuming that it is unreasonable for a library L to guarantee ABI compatibility from one version to the next, would there still be a reason to use inline namespaces to version that library?
Yes, this is the best reason to do so. Imagine a static library A that has been built against version 1 of L, and then an application that is trying to consume version 2 of L and the prebuilt library A. Without version-specific namespaces, there is a very good chance that this will successfully link, but then fail in some unspecified (and probably horrible, or worse: subtle) way at runtime. With version-specific namespaces, this will fail to link until the user either switches the application to use v1 of L or rebuilds A to use v2 as well. The above assumes that v2 of L does not define the namespace that v1 used. If instead v2 defined "ABI compatible symbols" in a v1-named namespace as well (which is harder), then the above scenario *might* link and even work correctly, assuming that either the app and lib A did not pass lib L's objects to each other, or that lib L defined ways to make them interoperable (which can also be hard).