Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at