On Wed, Dec 2, 2020 at 9:20 AM Edward Diener via Boost
On 12/2/2020 4:03 AM, Alexander Grund via Boost wrote:
IMO it would be enough on a cost-benefit ratio to go to C++11 by basically banning the use of MPL in Boost (the single-worst offender on compile times) and reducing the use of type_traits to the absolute minimum.
Feel free to offer PRs to those C++98/C++03 libraries to transition them from MPL to mp11 and from Boost type traits to standard type traits so that they can become C++11 libraries.
+1.
Nothing is going to be banned, but Alex is encouraged to convince
library authors to update their libraries in this way, and encouraged
to offer to help them in doing so.
Glen
On Wed, Dec 2, 2020 at 9:20 AM Edward Diener via Boost
On 12/2/2020 4:03 AM, Alexander Grund via Boost wrote:
That's not what I have in mind. Macros don't solve the problem. What I have in mind is that there is a single library that, in its interface, can seamlessly take either boost::fs::path or std::fs::path, without the user having to define anything.
Of course, when building the library, you probably would need to have Boost.Filesystem available.
This may work for simple types like string_view. But it won't work for (non-header-only) libraries using e.g. fs::path. At some point you have to convert to either type or to a third and that is gonna cost you
Additionally that interface may need includes to either or would require the user to include that first introducing an include-order issue.
And finally once you return a type you have no way for "either" (again except for simple types that could on-the-fly convert) and that too requires an explicit choice for the include.
IMO it would be enough on a cost-benefit ratio to go to C++11 by basically banning the use of MPL in Boost (the single-worst offender on compile times) and reducing the use of type_traits to the absolute minimum. Those 2 are (transitively) in the largest chunk of boost libraries and hence hit hard on compiletimes. Then using the std smart-pointers wherever possible would further untangle the libraries. So basically a bottom-up approach to improvement instead of a fork to whatever is the current greatest and latest. This could even be done for/by GSoC, interns or similar. And in ~8 years one can check if C++17 would be a good base point.
Feel free to offer PRs to those C++98/C++03 libraries to transition them from MPL to mp11 and from Boost type traits to standard type traits so that they can become C++11 libraries. I do have the greatest admiration for mp11 so I am not being facetious. But "banning" MPL and Boost type traits is going to currently remove a great number of libraries from Boost. I do agree that a bottom up approach is necessary to transition Boost libraries to C++11 since a given Boost C++98/C++03 library has dependencies on other Boost C++98/C++03 which themselves use the Boost rather than the equivalent standard library.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost