Re: What to do about Boost libraries which use user-defined macros which are not BOOST_ prefixed

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-12-16 18:22:01

> When using the above code snipped (making the old one an error) how long
> will you keep it?
> - Very long: You still block the macro you wanted to free
> - Short: Users skipping versions won't notice the change until it's to
> late. We jumped from 1.55 to 1.67 not so long ago...

We need to stop *defining* non-BOOST_ prefixed macros in Boost. Or
injecting anything into the global namespace. Even if we #undef it later.

We can however *react* to anything already in the global namespace. It's
not us being anti-social, it's us reacting to other code's anti socialness.

So, to answer your question, you detect the old setting where the new
setting is not applied, and give a useful error (my preference) or
warning (Peter's preference).

> Is the condition `if defined(PHOENIX_LIMIT) &&
> !defined(BOOST_PHOENIX_LIMIT)` even justified? What if someone else
> defines BOOST_PHOENIX_LIMIT and my library/app defines PHOENIX_LIMIT?
> Now I don't get an error and stuff breaks when I don't expect it.

I'd be happy with "#ifdef PHOENIX_LIMIT" then error out personally.

Niall