Re: [boost] C++03 / C++11 compatibility question for compiled libraries

Subject: Re: [boost] C++03 / C++11 compatibility question for compiled libraries
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-02-19 16:53:07

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
>