On Thu, Dec 28, 2023 at 5:42 PM Peter Dimov via Boost <boost@lists.boost.org> 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