C++ Weekly - Ep 320 - Using `inline namespace` To Save Your ABI

☟☟ Awesome T-Shirts! Sponsors! Books! ☟☟

Upcoming Workshop: C++ Best Practices, NDC TechTown, Sept 9-10, 2024
Upcoming Workshop: Applied constexpr: The Power of Compile-Time Resources, C++ Under The Sea, October 10, 2024

T-SHIRTS AVAILABLE!

WANT MORE JASON?

SUPPORT THE CHANNEL

GET INVOLVED

JASON'S BOOKS

► C++23 Best Practices

► C++ Best Practices

JASON'S PUZZLE BOOKS

► Object Lifetime Puzzlers Book 1

► Object Lifetime Puzzlers Book 2

► Object Lifetime Puzzlers Book 3

► Copy and Reference Puzzlers Book 1

► Copy and Reference Puzzlers Book 2

► Copy and Reference Puzzlers Book 3

► OpCode Puzzlers Book 1


RECOMMENDED BOOKS

AWESOME PROJECTS

O'Reilly VIDEOS

[Phroggster]

Not sure how this "one nifty trick big ABI doesn't want you to know about" never made it onto my radar, but that is a really nifty feature. Thanks Jason.

[lincolnsand]

Wow, that's a fantastic little feature for loudly breaking ABI without breaking API. I'm surprised I'd never heard about it until just now.

[MarekKnapek]

Win32 does this (in C) by having `int version` as first data member of many structs. They have single `calculate_things` function that checks the version number and acts accordingly (for example dispatches to `calculate_things_v1` or `calculate_things_v2`). Except `int version` is actually called `DWORD cbSize`. It works fine with no problems for 30 years already.

[Deniz.Bahadir]

One annoying "problem" which I experienced when we applied this at my former employer's code base is that you cannot simply forward-declare some type that comes from an(other) inline-namespace. You always have to know in what exact inline-namespace the to-be-forward-declared type resides and open that full namespace in order to forward-declare that type.
Of course, this is probably more of a feature than a bug...

However, at least one compiler (Clang?) complained (with a warning) if I tried to forward declare a type from an inline-namespace but did not use the 'inline' keyword (and vise versa). ("Reopening an 'inline' namespace without 'inline' specifier." or some similar warning.)
This can be really annoying if the default changes and suddenly another namespace got the 'inline' keyword. Then one needs to adjust all forward-declarations to silence the compiler warnings.

(I am the "treat all warnings as errors" guy, who does not like fixing warnings by ignoring them.)

[nmmm]

Nice one. Did not know this.

One minor remark, inline namespace works from C++11, not 17.

I am wondering, why there are inline "anonymous" namespace, e.g.

inline namespace {
// This compiles...
}

[mjKlaim]

I've been aware of this feature since it was introduced and been following what people (boost mostly) experienced with it and while it is helpful, it doesnt solve much of the ABI problems we keep hitting in the committee these days, like for example the fact that we can break accidentally ABIs all the time (tools help but they are hard to be setup by default). Note also that there is a similar system fo C abis in unix implementations (so non-standard), which have been introduced around the string C++11 abi breakage if I understand correctly. For some reason it is not considered manageable to use these mechanisms for the stl (it's not clear to me why).
Interesting reads about the subject: (see wg21.link slash paper number for accessing these papers):
- Herb Sutters proposiation about introducing some predictable breakage of ABI, which was kind of rejected at the time: N4028
- The most promising proposal to help handle ABI breakage in a more powerful but similar way to inline namespaces: P2123
In particular, from P2123:

> Some C++ standard-library implementations, such as libc++, use C++ inline namespaces and these may succeed at providing a partial strategy for dealing with ABI/API transitions. std::vector is really std::__1::vector, and so on. With all of the usual caveats about return types not being part of the name mangling on some systems, this can provide unique symbol names when using types from different (inline) namespaces. However:

- The inline namespace technique is not viral: it affects only direct uses of the standard-library types. User types that use standard-library types are not automatically tied to the same versioning scheme, and so, the inline namespace technique does not help user-defined types in the same way.

- On some systems, it doesn’t even help standard-library types if they’re used only as return types.

- It’s not clear how we might use this technique to manage ABI transitions directly.
[...]

[Raspredval]

it's actually shockingly simple. Like why THIS never gets into any c++ guidelines and books?

[victoreijkhout]

Pretty brilliant! And presumably you could write an ABI-agnostic version, and let your versioned namespaces call to it?

[marco]

This cannot only fix ABI compatibility but behaviour too. Anyway I think container are an even better approach for many usecases.

[embeddor]

Aren't modules supposed to fix this problem, as we would no longer have the "two sources of truth"-problem?

[DamianReloaded]

One would have to preemptively wrap all public structs of a library in the first version just in case any of those ever needs to change in the future (?)

[Sebanisu]

I think I've only seen this in the fmt library. I might add this to my code.

[redcrafterlppa]

Would it be practical to use a preprocessor macro to change the namespace name according to the build version?

[dwarftoad]

Could you also make a copy of the old code, but in an explicit (non-inline) namespace with the old name, and have old programs keep working?

[SlentStrm]

Simple Solution: Static link everything and no issues Kappa

[petermuller]

Unfortunately, this is just one of the "keeping honest people honest" practices. While ABI aware folks use it to ensure ABI compatibility, far too often I see it cargo culted without understanding what's actually necessary to ensure ABI compatibility

[LL-rnrn]

As CPUs are getting more caches, will there be videos for such optimization.