Re: [boost] C++03 / C++11 compatibility question for compiled libraries

Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-02-20 00:37:08

On 20/02/2018 08:22, Robert Ramey wrote:
> On 2/19/18 10:30 AM, Edward Diener wrote:
>> The problem with your definition of "dropping support for C++03" is 
>> that end-users of Boost libraries need to be told that Boost no longer 
>> can guarantee that a library which currently works in C++03 mode will 
>> continue to do so.
> 
> Hmmm - I'm not aware of any such guarantee.  I believe that if I wanted 
> to, I could update the serialization library so that it henceforth it 
> would only work under C++11, 14, or ...
> 
> Of course there's no reason I would want to do that - and of course no 
> reason that I should be required to do that - and in any event, there 
> would be no way of enforcing such a requirement.

It hasn't been merged to the "main" site yet, but prior discussion on 
this topic led to the creation of this section:

 
https://beta.boost.org/development/requirements.html#Backwards_compatibility

Part of the API contract of a library is which compilers it can be 
compiled with, which includes the C++ standard conformance level. 
Dropping support for older compilers or increasing the minimum 
conformance level (which also can drop support for older compilers) thus 
ought to be treated as an API breaking change.

Which are not forbidden, but are generally considered bad manners unless 
there's a clear migration path and time to make that migration.

Supporting C++11 in a library (eg. adding move constructors where 
appropriate) can be done in a manner that still compiles on C++03 
compilers, thanks to Boost.Config; although things do get more complex 
in mixed environments if eg. the C++03 and C++11 layouts of std::string 
for the same compiler and STL differ.

Having said that, I'm personally not opposed to encouraging (but not 
requiring, since the CMT is overloaded) a C++11 baseline.  I do have 
some projects that (for various reasons) are stuck in MSVC9, but they 
are also stuck with an older Boost release for similar reasons anyway.