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

From: Edward Diener (eldiener_at_[hidden])
Date: 2019-12-16 21:32:19

On 12/16/2019 11:58 AM, Alexander Grund via Boost wrote:
> 
> On 16.12.19 17:38, Edward Diener via Boost wrote:
>> On 12/16/2019 10:22 AM, Niall Douglas via Boost wrote:
>>> #if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT)
>>> #error In Boost 1.xx PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT.
>>> Please upgrade your code to reflect the new name.
>>> #endif
>>
>> I am with Niall in this as I think that all Boost library macros 
>> should begin with BOOST_SOMELIBRARY_UPPERCASENAMEOFMACRO_ETC. Maybe we 
>> can, in general, deprecate the current macros that do not follow this 
>> pattern and then change them to this pattern in some future Boost 
>> release. Needless to say it is really important that C++ macro names 
>> are as distinct as possible. We all know how ridiculous it is for 
>> compiler implementations to name macros with names such as 'max' and 
>> 'min' and all the troubles such names have caused for scores of C++ 
>> programmers down through the years. 
> 
> I do understand Peter though: This is dangerous!

You can eventually put in a common header included by all library XXX 
headers:

#if defined(XXX_SOMEMACRO)
#error the correct definition for XXX_SOMEMACRO is now 
BOOST_XXX_SOMEMACRO. Please make the change in your source code.
#endif

I understand that this may be annoying, but I think it is eventually 
worth it. Boost could also provide a Python script to change the name of 
macros to their Boost equivalent for all source files which may use 
library XXX etc.

I understand that a macro named PHOENIX_SOMETHING is a pretty specific 
macro name in its own right, and is probably never going to be 
duplicated at a practical level in non-Phoenix code anywhere, so I am 
not trying to be doctrinaire about Niall's suggestion. But I think the 
suggestion is generally right in trying to avoid macro name clashes.

> 
> Most of the macros have default values, so when changing the name, users 
> won't notice and applications will continue to work. Until they don't.
> 
> 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...
> 
> 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.
> 
> My proposal: Evaluate each macro carefully.
> Where changing the macro issue a deprecation message (suppressible per 
> macro) for a couple releases (3? 5? 10?) when the old one is defined.
> Only change macros where not defining it by the user will lead to 
> compile-time errors. E.g. for BOOST_PHOENIX_LIMIT I think this was the 
> maximum number of arguments supported and not defining it bigger will 
> make code using more args fail to compile. This would be OK.
> For other macros provide a BOOST_ version and error out if both are 
> defined. So users can start using the "good" ones and docs should only 
> mention them (or hide the old names under a "see there")
> But the old ones must be kept for those. Mistakes were made, can't 
> really change that now.