Boost logo

Boost :

Subject: Re: [boost] Seeking advice regarding inline namespaces
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-11-12 07:24:55

> 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?


View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at