Boost logo

Boost :

Subject: Re: [boost] A possible date for dropping c++03 support
From: Roger Leigh (rleigh_at_[hidden])
Date: 2018-08-28 15:48:36

On 28/08/18 16:17, Edward Diener via Boost wrote:
> On 8/28/2018 1:11 AM, Mike Dev via Boost wrote:
>> Dear Edward,
>> throughout this thread you keep saying that you or the user will
>> not understand what
>>     "dropping c++03 support"
>> means and I have to say I find that very hard to believe, as the
>> concept of "XXX is not supported" is ubiquitous throughout software
>> development.
> It astounds me that you can not understand that the statement "Boost
> dropping c++03 support" is a generality that can mean whatever you think
> it means, and that you keep pushing for such a statement being
> universally understand by everyone with no further explanation needed.
> As you can clearly read by other respondents in this thread, and not
> just me, you are dead wrong in your assumption. When some poor end-user
> reads "Boost dropping c++03 support" and finds he is still able to
> compile some Boost library in C++03 mode and asks why a statement was
> made of "Boost dropping c++03 support", I nominate you as the one to
> explain to him that

"Not supported" does not mean "not functional". It means that it's...
not supported by the project's developers.

If it does by chance happen to work, there are no guarantees that it
works correctly or will continue to work correctly. The risk of using
it is entirely in the hands of the end user.

For several of the projects I work, or have worked, on there are plenty
of platforms and configurations which work perfectly well in practice
but aren't supported at all. We have to constrain ourselves to a
limited subset of the possible to provide meaningful support to our
users/clients, typically the platforms and configurations they care
about, and if an end user steps outside that supported subset of
possibilities then they do so on their own at their own risk. The
organisation/company would not /officially/ support such use.

Incidentally, in my previous role we had a lifecycle of support for all
dependencies including compilers and libraries which was broadly:

   unsupported (new) [not yet tested or qualified]
   supported (newer versions)
   supported (recommended) [preferred version]
   supported (older versions)
   supported (deprecated)
   unsupported (old)
   unsupported (known broken)

If C++03 is currently "supported (older version)" then it could be moved
to "supported (deprecated)" to officially deprecate it. If C++11 became
a hard requirement which would break C++03 support then it would become
"unsupported (known broken)" or else it would be "unsupported (old)"
(untested, but might work).

We would have a matrix of each of GCC, Clang, MSVC and Boost versions
(as well as all other dependencies) with our product versions on the
other axis so that it was clear what was supported for every version,
and made it clear what the support window was for existing and future
releases. You would see new GCC, Clang, MSVC and Boost releases go
through all the above phases over time with new product releases.


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