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

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2019-12-17 13:59:21

On 17.12.19 14:50, Edward Diener via Boost wrote:
> On 12/17/2019 2:39 AM, Alexander Grund via Boost wrote:
>> So you want to forbid using e.g. PHOENIX_LIMIT for everyone using 
>> Boost.Phoenix? What about in 2 releases after that change someone new 
>> comes in and uses the new Boost (the first he has ever used) together 
>> with some libPhoenix he wrote and (appropriately) uses PHOENIX_LIMIT 
>> as the same for his macros?
>> So what is gained?
>
> It is a macro. Macros do not go into libraries. The libPhoenix he 
> wrote has nothing in it regarding the name PHOENIX_LIMIT. If your 
> hypothetical programmer uses PHOENIX_LIMIT in his code he is told via 
> the preprocessor #error that he must use BOOST_PHOENIX_LIMIT instead.

You misunderstood me. If you (currently) include a header from 
Boost.Phoenix then PHOENIX_LIMIT will be defined (unless I missed an 
undef somewhere)

So assume the following:
- PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT
- An error was added if PHOENIX_LIMIT is defined
- A user develops a libPhoenix (unrelated to boost) and uses 
PHOENIX_LIMIT as per `<libName>_<macro>` naming convention to do 
something in the headers of his library (e.g. a constant to cap numbers)
- A user (the same or another) uses libPhoenix and BoostPhoenix and 
includes their headers in this order

--> libPhoenix headers rightfully define PHOENIX_LIMIT, Boost headers 
detect the "old" name and error out. Boom, broken some unrelated library 
for no (apparent) reason