From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2020-11-30 01:18:53
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.