Re: improve <boost/config.hpp>

From: Jeff Garland (azswdude_at_[hidden])
Date: 2023-03-08 15:11:33

On Tue, Mar 7, 2023 at 11:11 AM John Maddock via Boost <
boost_at_[hidden]> wrote:

>
> > Not every compiler defines these macros. Let alone, not every compiler
> > properly implements what it advertises.
> I think it depends on the compiler - the current crop of the latest are
> pretty good at getting these right.
> > Also, library-defined macros are worthless as they only allow one to
> > know the feature is/isn't supported after including the header, i.e.
> > after the fact. C++20 <version> fixes this, but C++20 is a too high
> > minimum bar to target.
> Sort of, you know that Boost.Config uses <version> wherever possible
> already?  It does so even in non-C++20 mode since the header is just a
> bunch of #defines and is perfectly usable back to C++98 if it exists.
> >
> > So no, feature macros do not replace Boost.Config. In fact, I'd prefer
> > to continue using Boost.Config in new libraries.
>
> There are still plenty of things Boost.Config is good for: particularly
> where getting the configuration correct is tricky - for example if you
> want to use <header> then you need to know both that it exists via
> __has_include, but also that the current language standard is sufficient
> to parse the header, and that it has been been fully implemented.
>
> On the other hand, for the suggested BOOST_NO_CXX20_CONSTEXPR,
> Boost.Config would implement this trivially as (__cpp_constexpr <
> 201907L) which is a less obvious win - except perhaps to save folks
> having to look up the value - which now I come to think about it, might
> be a win after all given that it's value is not 202002L ;)
>

To me, cppreference is only a click away so I'm unmoved by the 'value being
unexpected'. I do appreciate that boost.config can compose for the more
complex cases and is tested to ensure portability.  Really my main thinking
here is a minimization of inter-boost dependency (for the aforementioned
stand alone capability).  Config is hardly a heavy dependency in the end so
if it's useful it can be pulled in by the cmake, but if there's an easy way
to check without it then that I think should be the first choice.  If it's
really the case that the macro coverage in implementations is as spotty as
some are implicating here -- then by all means use config -- I'm just
thinking I won't really need it going forward.

Jeff