On 12/11/2015 06:26, Louis Dionne wrote:
[...] (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).
Ok, but since L can't guarantee ABI compatibility at all between versions, this means that such a version namespace must change between each version to ensure that you get a linker error even between v1.0.0 and v1.0.1, correct? In other words, what you want is Version 1.0.0: namespace L { inline namespace v1_0_0 { } } Version 1.0.1: namespace L { inline namespace v1_0_1 { } } Version 1.0.2: namespace L { inline namespace v1_0_2 { } } ... and so on, for literally each released version of the library L. Is this correct? Regards, Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Seeking-advice-regarding-inline-namespace... Sent from the Boost - Dev mailing list archive at Nabble.com.