Boost logo

Boost :

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
>> 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

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

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at