On 13/11/2015 01:24, Louis Dionne wrote:
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?
Yes, if you want to provide that feature to your users, then that's how to do it. Typically you'd have a macro or the namespace decls in some prefix header so you don't have to repeat yourself too much.
The easiest thing to do is to provide a common version namespace for everything, but you could instead decide to version each type individually and increment them only when actually modified.
There are other things you can do to reduce potential ABI breakage, such as using #pragma pack. This is less important for most consumers, though, as most apps don't play with the packing.
There are also other compiler settings you can take into account in your namespace name when you know that they affect ABI, eg. whether exceptions are enabled or not. I can't think of a specific example at the moment but I know at least one Boost library does this.
Ok, thanks a lot for the information. Keeping this in mind, I'll consider whether the added complexity of versionning Hana's namespace seems to be worth it (given the nature of Hana as a metaprogramming library). 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.