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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk