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