Re: Interest in new parsing library?

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2023-12-29 18:25:32

On Thu, Dec 28, 2023 at 5:42 PM Peter Dimov via Boost
<boost_at_[hidden]> wrote:
>
> Zach Laine wrote:
> > Dependencies are still a nightmare in C++, so Boost.Parser can be used as a
> > purely standalone library, independent of Boost.
> ...
> > The presence of Boost headers is detected using __has_include().
>
> That's not a good idea. Depending on random features of the environment
> for ABI-incompatible changes will create many more problems than it would
> solve. Just use a macro.

That might be true in general, but I don;t think it is given how I'm
using them.  __has_include is only used in 4 places:

1) To detect Boost.Preprocessor headers.  If detected, Boost.Parser
defines a convenience macro that uses Boost.Preprocessor macros.
2) To detect <coroutine>.  If detected, it is included; this is
necessary because at least one implementation reported
__cpp_impl_coroutine but did not provide the header. This is cruft
that I can remove, but is otherwise harmless.
3) To detect <boost/type_index.hpp>.  If it's available, it is used to
print type-names; otherwise, <typeinfo> is used.
4) To detect <boost/assert.hpp>.  If present,
BOOST_PARSER_DEBUG_ASSERT is BOOST_ASSERT; otherwise, it's just
assert.

Only 3 and 4 could result in a different string of tokens for the same
function in 2 TUs.  But that problem could exist even without this
technique -- if I built 2 TUs, each with a different version of Boost
in the default system paths, I could get a different string of tokens,
and violate ODR.

If this is overly simplistic, I can make a change.  I do like the
current approach because I find it very user-convenient.

Zach