Boost logo

Boost :

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2019-12-16 16:58:12

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!

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