Boost logo

Boost :

Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries
From: mike.dev_at_[hidden]
Date: 2018-02-19 20:57:52

Sorry for my poor English,

Apparently, people understood the exact opposite of what I wanted to say.
I'll try again: The question I tried to answer
(although it wasn't addressed at me) was

> What does "drop support" mean?

So I tried to explain, what I - as a boost-outsider - would expect to happen
a year or so after such an announcement was made (by whoever had
the authority to do so)

> > What I generally expect "dropping c++03 support" to mean are the
> > following things:
> > - Any library may start to use c++11 features at any point without
> > prior announcement and/or without having to wait a few releases
> > it is no longer considered a breaking change).
> This is and always has been the standard policy for all C++ versions.

I was not aware of this. Till now it seemed that boost library maintainer
put great emphasis on not making any breaking changes without
prior announcement. This is also reflected here:

> Boost libraries generally have a large and diverse user base.
> To ensure successful transitions from old APIs to newer APIs under
> those circumstances, library authors are encouraged to follow a few
> guidelines when introducing breaking changes in their library:
> [...]
> Small breaking changes can be made, but users should be given
> **notice a few releases before the change is published**.
> [...]

I'm pretty sure, changing the minimum required c++ version from 03 to 11
does imho qualify as a breaking change and according to above note it
should be announced several versions in advance.

> On 2/19/2018 4:51 AM, Mike via Boost wrote:
> > - Any library may start to use c++11 features at any point without
> > prior announcement and/or without having to wait a few releases
> > it is no longer considered a breaking change).
> I think that it is a breaking change in that end-users who previously
> in C++03 mode when using such a library can no longer do so. Of course if
> Boost wants to tell end-users that compiling any particular library in
> mode is no longer guaranteed to work, even if it has worked previously,
> this would no longer be a breaking change.

That exactly what I said: Currently it would be considered a breaking change

And would have to be announced some time in advance.
*IF* support for 03 was dropped I'd no longer consider it a breaking change

> > - c++03 builds are removed from the test matrices
> The test matrices are up to those contributing them. If you would like to
> suggest to them that testing in C++03 mode is wasteful, please feel free
> do so.

*IF* support for 03 was dropped I would indeed consider this wasteful.
Currently I don't.

> > - Compilation paths that are c++03 only can be removed (thus
> > simplifying the code base and future refactoring/development)
> Any library developer can always do this now as a potential breaking

Yes, but as I said, I believe there is currently a certain peer pressure to
Not make such a breaking change (even with prior announcement)

> > - My hope (obviously no one can or should force a volunteer to do
> > anything) is that - where applicable - libraries start to replace
> > types & functions that have been merged into the c++11 standard with
> > their std equivalent or the equivalent c++11 language feature.
> Using std versus boost libraries is almost always equivalent to working
only in
> C++11 mode or above.

Yes, that would exactly be the consequence of dropping c++03 support

> > - In the long run, libraries that have been fully merged into c++11
> > could be deprecated and removed all together.
> What does "fully merged into c++11" mean ? Requires C++11 mode to work ?
> If a library which previously worked in C++03 mode is changed so that it
> requires C++11 mode on up, why would you want to remove or deprecate it
> ?

It is not about a boost library being changed, but about a boost library
Being integrated into the c++11 standard. "Fully merged into c++11" means
that there exists a functionality in c++11 that can completely replace
the equivalent boost member (e.g. std::array vs boost::array)
I believe, there are libraries where the boost version is actually
more powerful.
I'm calling this merged into c++11, as I consider boost somewhat of
an experimental / development branch of the standard c++ library.

> > [...]
> OK, at least this is your definition of what "dropping support for
> C++03" means.

Yes, that is what I said at the very beginning of my post:
> What *I* generally expect "dropping c++03 support" to mean

> 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
> do so. This announcement as I see it would have to be determined by the
> Boost Steering Committee and announced on the website, as a minimum. I
> am not personally against doing so, but I am also glad I am not involved
in any
> way ofd making such a decision.

I thought that this is exactly what this discussion was about
(not the original question of the thread, but the spinoff)
But just to be clear: I'm not a boost developer/contributor and while
I personally think dropping c++03 support would be the right thing to do,
I feel neither qualified nor do I have the influence to promote such an
agenda. I just wanted to explain my understanding of
"dropping c++03 support".

> I am personally against dropping libraries
> from Boost just because they happen to work in C++03 mode, when that
> library also works fine in C++11 mode on up.

I'm sorry if I made the impression that I'd advocate this.
I don't think anyone is suggesting this and actually I wonder if people
implying this are raising a strawman here.

What I like like to see in the long run is the removal of boost libraries
that are superseded by c++11 libraries.

So, I hope I could clear up things a bit and did not confuse further.

Cheers and Best regards


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