Boost logo

Boost :

From: René Ferdinand Rivera Morell (grafikrobot_at_[hidden])
Date: 2022-12-23 19:46:44


On Fri, Dec 23, 2022 at 12:33 PM John Maddock via Boost
<boost_at_[hidden]> wrote:
>
>
> >> Is someone willing to explain to me why we have Predef and Config?
> > There are probably a couple of people who can explain. I might even be
> > one of them. And this would be easier to explain if the Config
> > documentation was better. Specifically in the area of stating its
> > goal, what it's meant to do, its domain of operation, its reason for
> > existence. Perhaps we are supposed to know everything just from its
> > name? Do we dare ask for someone to volunteer such information be
> > communicated in the documentation? Or do we all just know?
>
> Perhaps we do (or not!)
>
> I see the two libraries as orthogonal: Config answers the question "does
> the current compiler/platform/std lib have feature X?" without the user
> needing to know anything about what the current compiler/platform/stdlib
> actually is. Where as predef provides a unified way to figure out what
> the current compiler/platform etc really is, and what version it is.
> This is obviously a brilliant fallback for situations when Config
> doesn't have a necessary feature test macro ;)

That, indeed, makes some sense. Predef aims to answer the who of it
all. While Config aims to answer the what of it all. Did I already
know this? Only I will ever know :-)

> I should also state, that Config was never really intended to be a
> library for the end user (though I'm aware that some do use it), indeed
> we rather discouraged end-user usage. Rather it was a bunch of shared
> configuration code, dating back to the heady days when there were only a
> handful of Boost libraries and everyone round here knew everything that
> was going on in each of them! Arguably it should be long dead by now,
> though I have to admit that I'm rather pleased it still mostly just
> plain works, and even the C++20 feature test macros are rather tedious
> to use in comparison (even though I was rather hoping they would
> eventually replace it).

That seems to be an eternal story for Boost. People wish for each new
version of C++ to replace something in Boost. And each new C++ edition
seems to fall short of that wish. Is that a good thing? As it keeps
our work relevant. Or is it a bad thing? That we are failing to impact
the standard per the ostensibly noble BoostORG goals. Should we
reconsider the goals of the Boost C++ Libraries?

> So they could be merged, or not. I'm not sure how much it matters
> either way ;)

Should it matter? Is it important to combine the who, what, where,
when of C++ functionality into one library? Hm, not even the standard
tries to do that. Should Boost do that? Should a single Boost library
do that?

-- 
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk