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.