I believe it will be useful. For example, BOOST_FOREACH can be implemented in terms of built-in range-based for if it's available. -- Best regards,   Alexander Fokin, http://elric.ru.

John Maddock wrote:

OK, but what I'm missing here is a boost-library author saying "I want to use this for X", or to put it another way, we don't add new macros just because we can - as there are too many of the things already!

I'm not a boost-library author, but would like to submit a patch (for boost/range/begin.hpp and boost/range/end.hpp) which needs BOOST_NO_RANGE_BASED_FOR. C++0x range-based for conflicts with many Boost libraries: (Remarkably, boost::iterator_range cannot be used in C++0x range-based for.) // case 1 #include <boost/range/iterator_range.hpp> for (auto x : boost::iterator_range<int*>(nullptr, nullptr)) {} // error // case 2 #include <boost/ptr_container/ptr_vector.hpp> for (auto x : boost::ptr_vector<int>()) {} // error // case 3 #include <vector> #include <boost/range/adaptor/reversed.hpp> for (auto x : std::vector<int>() | boost::adaptors::reversed) {} // error // case 4 #include <boost/algorithm/string.hpp> #include <boost/array.hpp> for (auto x : boost::array<int, 2>()) {} // error // case 5 #include <vector> #include <boost/shared_ptr.hpp> #include <boost/range/algorithm.hpp> for (auto x : std::vector<boost::shared_ptr<int> >()) {} // error All these errors are caused by ambiguity between std::begin/end and boost::begin/end. I've already made a patch to resolve this issue and I will submit a patch after BOOST_NO_RANGE_BASED_FOR is ready on trunk. Regards, Michel

On Fri, Dec 17, 2010 at 6:55 AM, John Maddock <boost.regex@virgin.net> wrote:

That's a problem, writing code both the "old" way and the "new" way (which is what boost authors would have to do, complete with all the #ifdef logic) is probably worse than just using the old style and be done with it.

Or you could just use BOOST_FOREACH and be done with it; whichever is more appropriate to your situation. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

On 17.12.2010, at 17:35, Michel MORIN wrote:

Sebastian Redl wrote:

...

...

C++0x range-based for is available on GCC 4.6 (Pre-release). There is no BOOST_NO_RANGE_BASED_FOR macro, so I made a patch against trunk and made a test case. Please see attached files. Is it reasonable to add this macro?

I don't think there's really a point, unless you want Boost's users to use the config macros. Range-based for is a convenience functionality, not an enabling functionality. In other words, if you can't use it all the time, but have to write the long form anyway, what's the point in using it?

Range-based for conflicts with many Boost libraries. This issue can be resolved by fixing boost/range/begin.hpp and boost/range/end.hpp, which needs BOOST_NO_RANGE_BASED_FOR macro.

No, a standard library that provides std::begin() and std::end() conflicts with boost::begin() and boost::end() provided by Boost.Range. These functions are used by for-range, so their existence is a requirement for a compiler supporting for-range on anything but arrays, but the language feature itself has nothing to do with the conflict. This is important because, for example, libc++ already has std::begin() and std::end(), but Clang doesn't yet support for-range.

Yeah, we can always use BOOST_FOREACH instead of range-based for. And considering portability, BOOST_FOREACH is a must. But IMHO it's a pity that users of the Boost libraries are recommended not to use a language feature.

Er, what? Who recommended that Boost users not use a language feature? Dave merely said that Boost authors should just use BOOST_FOREACH. Sebastian

On Fri, Dec 17, 2010 at 1:17 PM, Michel MORIN <mimomorin@gmail.com> wrote:

I just wanted to say it is important to fix boost/range/begin.hpp (end.hpp) so that the following code does compile.

   #include <boost/range/iterator_range.hpp>    int main(int argc, char* argv[])    {        int ar[2] = {2, 2};        boost::iterator_range<int*> rng(ar, ar + 2);        for (int i : rng) {} // error: ambiguous calls        return 0;    }

+1 to that, brother! -- Dave Abrahams BoostPro Computing http://www.boostpro.com