|
Boost : |
From: Edward Diener (eldiener_at_[hidden])
Date: 2020-12-02 14:20:32
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk