automatic ranged for over integer failure

Hey all, another weird question.

I had written a ranged type that instantiates over any integer type so that I could write a simple for loop as, for example:

for (auto n: 100)

instead of the more unwieldly:

for (int n = 0; n < 100; n++)

With properly overloaded versions of begin() and end() it worked swimmingly.

However, the latest GCC doesn't seem to like that any more. It only works on class types:

for (auto n: my_range(100))

...in which case I might as well just use the Boost::irange or Boost::counting_range adaptors.

Has anyone else played with this? What is making GCC fail to use my overloaded begin() and end()?

1
2
3
4
5
6
template <typename T> inline
typename std::enable_if <std::is_integral <T> ::value, duthomhas_integer_range_t <T> > ::type
begin( T N )
{
  return duthomhas_integer_range_t <T> ( T() );
}

(Also, I haven't played with this in VC++ yet, so IDK how it behaves.)
Last edited on
This is how it should behave according to standard:

2011 Standard wrote:
6.5.4/1 [stmt.ranged]
β€” otherwise, begin-expr and end-expr are begin(__range) and end(__range), respectively, where begin and end are looked up with argument-dependent lookup (3.4.2). For the purposes of this name lookup, namespace std is an associated namespace.

3.4.2/2 [basic.lookup.argdep]
For each argument type T in the function call, there is a set of zero or more associated namespaces and a set of zero or more associated classes to be considered. The sets of namespaces and classes is determined entirely by the types of the function arguments (and the namespace of any template template argument). Typedef names and using-declarations used to specify the types do not contribute to this set. The sets of
namespaces and classes are determined in the following way:
β€” If T is a fundamental type, its associated sets of namespaces and classes are both empty.

So as int is a fundamental type, your overload will not be found at all.

EDIT: it is even better, C++14 changed wording eliminating slight ambiguity:
2014 Standard wrote:
6.5.4/1 [stmt.ranged]
β€” otherwise, begin-expr and end-expr are begin(__range) and end(__range), respectively, where begin and end are looked up in the associated namespaces (3.4.2). [ Note: Ordinary unqualified lookup (3.4.1) is not performed. β€”end note ]
So not it is doubly working as it should.
Last edited on
Well, crap. I knew it would be something like that.

I can guess why they excluded fundamental types like that, but integers, at least, make sense here.

Crud.
Topic archived. No new replies allowed.