C++03 / C++11 compatibility question for compiled libraries
Hello everyone, I hope it is ok, for me as a non-boost-dev, to chime in here. 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 (I.e. it is no longer considered a breaking change). - c++03 builds are removed from the test matrices - Compilation paths that are c++03 only can be removed (thus simplifying the code base and future refactoring/development) - My hope (obviously no one can or should force a volunteer to do anything) is that - where applicable - libraries start to replace boost types & functions that have been merged into the c++11 standard with their std equivalent or the equivalent c++11 language feature. - In the long run, libraries that have been fully merged into c++11 could be deprecated and removed all together. Just to be clear: Dropping c++03 support doesn't mean a developer is forced to use c++11 constructs (if we ignore the potential future removal of boost libraries) - it primarily means that a user can no longer rely on the lib being usable in c++03 mode. And yes, this could be done on a per library basis, but especially older boost libraries are so tightly coupled that such decisions affect a lot of other libraries anyway. So my guess is that very few maintainers would dare to drop c++03 support as long as that hasn't been deemed acceptable by larger parts of the boost community.j Best regards Mike -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
On 2/19/18 1:51 AM, Mike via Boost wrote:
Hello everyone, I hope it is ok, for me as a non-boost-dev, to chime in here. 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 (I.e. > it is no longer considered a breaking change).
This is and always has been the standard policy for all C++ versions.
- c++03 builds are removed from the test matrices
Tests are run by volunteers. Volunteers are free to run tests under any environment they prefer. Of course they have no guarantee that any particular library will run in any particular environment. For example, hana won't run with a compiler which is not C++14 conforming. This is OK. In fact, there is a mechanism whereby a library author can specify which platorms should be skipped.
- Compilation paths that are c++03 only can be removed (thus simplifying the code base and future refactoring/development)
Hmmm - by whom. Library authors can already avoid use of deprecated C++ features/library components if they desire.
- My hope (obviously no one can or should force a volunteer to do anything) is that - where applicable - libraries start to replace boost types & functions that have been merged into the c++11 standard with their std equivalent or the equivalent c++11 language feature.
Authors might or might not do this. Generally Boost hasn't tried to specify a preference for using std or boost libraries when the functionality overlaps. I don't think it even could. std and boost libraries of the same name (e.g. thread) are equivalent in some contexts and not equivalent in others.
- In the long run, libraries that have been fully merged into c++11 could be deprecated and removed all together.
In the long run... Actually, I would like to see us sever the coupling between the exhaustive list of boost libraries and the deployment. So when it comes to downloading/installing, one could/would specify a "flavor". For example, there might be a "minimal" flavor which would include only those boost libraries for which there is no std equivalent. There might be an "exhaustive" flavor which includes everything. There might be a "networking" or text processing flavor, etc. In fact, users can easily implement this now with just a little git foo. a) clone the boost project form git hub b) run one of the dependency checkers on the libraries you expect your apps to call. c) delete the directories of the subprojects for the libraries you want to exclude. d) build boost on your local machine e) run the tests on it. Voila - you have your own custom, personalized version of boost which supports everything you need without having to wait for anyone else to do anything.
Just to be clear: Dropping c++03 support doesn't mean a developer is forced to use c++11 constructs (if we ignore the potential future removal of boost libraries) - it primarily means that a user can no longer rely on the lib being usable in c++03 mode.A user cannot rely on this now. He has to verify this by inspecting the
documentation and/or the code of the library. Or use the normal method - just include the libraries I want in my app, build it and see if crashes.
And yes, this could be done on a per library basis, but especially older boost libraries are so tightly coupled that such decisions affect a lot of other libraries anyway. So my guess is that very few maintainers would dare to drop c++03 support as long as that hasn't been deemed acceptable by larger parts of the boost community.j
It's already being done on a library by library basis. Newer libraries like Hana just support the latest standard. Older ones like serialization support C++03 to C++17. Each decision is appropriate for the context in which that library is being used.
Best regards Mike -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 2/19/2018 4:51 AM, Mike via Boost wrote:
Hello everyone, I hope it is ok, for me as a non-boost-dev, to chime in here. 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 (I.e. it is no longer considered a breaking change).
I think that it is a breaking change in that end-users who previously compiled 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 C++03 mode is no longer guaranteed to work, even if it has worked previously, then this would not longer be 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 to do so.
- 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 change.
- My hope (obviously no one can or should force a volunteer to do anything) is that - where applicable - libraries start to replace boost 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.
- 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 ?
Just to be clear: Dropping c++03 support doesn't mean a developer is forced to use c++11 constructs (if we ignore the potential future removal of boost libraries) - it primarily means that a user can no longer rely on the lib being usable in c++03 mode.
OK, at least this is your definition of what "dropping support for C++03" means.
And yes, this could be done on a per library basis, but especially older boost libraries are so tightly coupled that such decisions affect a lot of other libraries anyway. So my guess is that very few maintainers would dare to drop c++03 support as long as that hasn't been deemed acceptable by larger parts of the boost community.j
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. 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 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.
Best regards Mike -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
On 2/19/18 10:30 AM, Edward Diener via Boost 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. Robert Ramey
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.
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
(I.e.
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: https://beta.boost.org/development/requirements.html#Backwards_compatibility (https://groups.google.com/forum/#!topic/boost-developers-archive/DzExeMhmlX Y)
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**. [...]
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
(I.e.
it is no longer considered a breaking change).
I think that it is a breaking change in that end-users who previously compiled 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 C++03 mode is no longer guaranteed to work, even if it has worked previously,
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. then
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 to 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 change.
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
boost
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 to 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 Mike
mike wrote:
Sorry for my poor English,
Apparently, people understood the exact opposite of what I wanted to say.
FWIW, and IMO, your post was very good in laying out what dropping support for C++03 would mean. I'd only take exception to "a library can start using C++11 without warning and this is not considered a breaking change". That's like saying "1+1 is not considered 2". It's not a matter of consideration; if a change breaks code, it's a breaking change, regardless of whether one considers it to be such. It's generally up to the maintainer to decide how to proceed with breaking changes, whether caused by switching to C++11 or otherwise changing things in an incompatible way. ("It's generally up to the maintainer" is true for mostly everything in Boost, including whether to support C++03 or not.) We don't break code without a good reason not because of administrative rules and policies that forbid us from doing so; we don't break code without a good reason because this creates needless problems for our users and tarnishes our reputation and our brand.
On 19 February 2018 at 20:57, mike via Boost
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: https://beta.boost.org/development/requirements.html#Backwards_compatibility (https://groups.google.com/forum/#!topic/boost-developers-archive/DzExeMhmlX Y)
Perhaps I should make this clearer (which is tricky as the site is static), but you shouldn't think of anything on the beta site as approved. I think I said in the email that I put it up so that people could read it easily and provide feedback.
participants (7)
-
Daniel James -
Edward Diener -
Gavin Lambert -
Mike -
mike.dev＠gmx.de
-
Peter Dimov -
Robert Ramey