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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk