Re: [boost] [config] Add BOOST_NO_RANGE_BASED_FOR macro?

Subject: Re: [boost] [config] Add BOOST_NO_RANGE_BASED_FOR macro?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-07-09 20:15:12

On Mon, Jul 9, 2012 at 4:57 PM, Marshall Clow <mclow.lists_at_[hidden]> wrote:

> On Jul 9, 2012, at 11:42 AM, Marshall Clow wrote:
> > On Jul 9, 2012, at 11:34 AM, Beman Dawes wrote:
> >
> >> On Mon, Jul 9, 2012 at 12:11 PM, John Maddock <boost.regex_at_[hidden]>
> wrote:
> >>>> 2) If you have to add a config flag, please match the CXX11 naming
> scheme
> >>>> and call it something like
> >>>> BOOST_NO_CXX11_RANGE_BASED_FOR
> >>>
> >>>
> >>> +1 for that name.
> >>
> >> I really don't want to change naming schemes this far into it. If we
> >> go down that road, we should also rename the 28 Macros that don't use
> >> that scheme.
> >>
> >> Are you suggesting we should just byte the bullet and change them all?
> >
> > Yes, I am.
> >
> > I suggest that we do the same thing that I did for 1.50 and all the
> BOOST_NO_0X_* macros.
> > Define new ones, make the old ones have the same value as the new ones,
> and then, down the road, kill off the old ones.
> >
> > See trunk/boost/config/suffix.hpp.
> >
> > I even think that renaming all the macros (while keeping the old names
> around; not necessarily changing client code) is worth doing for 1.51.
>
> (Putting his money where his mouth is)
>
> Here's a patch vs. the trunk which renames all the macros in the table
> "Macros that describe C++11 features not supported" (with the notable
> exception of BOOST_NO_LONG_LONG) to have consistent names.
> For example:
>         BOOST_NO_VARIADIC_MACROS --> BOOST_NO_CXX11_VARIADIC_MACROS
>
> All the old names are then #defined to be the same as the new names;
> All the code and tests in config has been updated to use the new names.
> All the old names have been put into the "Boost Deprecated Macros" table.
>
> The goal here is no changes to client code (including code in boost
> outside of the config library).
> This seems to work fine on my system (Mac with gcc and clang)
>
> Now Beman can define "BOOST_NO_CXX11_RANGE_BASED_FOR" and it will match
> the style with other macros.
>
> Comments?

Why, again, are we preferring inserting CXX11 versus not? I.e., why is
BOOST_NO_CXX11_RVALUE_REFERENCES better than BOOST_NO_RVALUE_REFERENCES?

- Jeff