On 29.11.20 22:32, Edward Diener via Boost wrote:
On 11/29/2020 2:14 PM, Raffi Enficiaud via Boost wrote:
On 27.11.20 09:58, Antony Polukhin via Boost wrote: [...]
Boost.Preprocessor works in whatever C++ level you want. It has no reliance on any C++ standard or Boost equivalent library, or any other Boost library. That does not mean you could not eliminate use of its macros in code if you have a better alternative.
My point is that the biggest blocker for larger adoption of Boost.Test is the size of monolithic Boost, not C++17 (which it supports). Boost.Test depends on various libs among which preprocessor. It is good design in a single library to reuse functions. But * Boost.Test is not shipping some additional feature on top of preprocessor, it is a client of it. Preprocessor is an implementation detail of Boost.Test. * Boost is not a single library (especially since "modular Boost"), it is an umbrella of libraries. Each library is addressing a specific need in the C++ world and has a specific target audience. Code reuse should be thought as a way to bring features faster to market, this is a price usually customer is ok to pay for. But then library coupling has various downsides, such as slowing wider adoption and harming retention. Preprocessor is a valuable library (especially now that I am trying to re-implement a tiny subset of it) but that dependency has to be put in the light of what it costs to customers, and the customers of boost.test and preprocessor have little overlap.