Any disadvantage of using const reference when iterating over basic types?

Question

I find myself using C++11 more and more lately, and where I would have been using iterators in the past, I now am using range-based for loops whenever possible:

std::vector<int> coll(10);
std::generate(coll.begin(), coll.end(), []() { return rand(); } );

C++03:

for (std::vector<int>::const_iterator it = coll.begin(); it != coll.end(); ++it) {
   foo_func(*it);
}

C++11:

for (auto e : coll) { foo_func(e); }

But what if the collection element type is a template parameter? foo_func() probably will be overloaded to pass complex (= expensive to copy) types by const reference, and simple ones by value:

foo_func(const BigType& e) { ... };
foo_func(int e) { ... };

I didn't give this much thought while I was using the the C++03-style code above. I would iterate the same way, and since dereferencing a const_iterator produces a const reference, everything was fine. But using the C++11 range-based for loop, I need to use a const reference loop variable to obtain the same behavior:

for (const auto& e : coll) { foo_func(e); }

And suddenly I wasn't sure anymore, if this wouldn't introduce unnecessary assembly instructions if auto was a simple type (such as a behind-the-scene pointer to implement the reference).

But compiling a sample application confirmed that there is no overhead for simple types, and that this seems to be the generic way to use range-based for loops in templates. If this hadn't been the case, boost::call_traits::param_type would have been the way to go.

Question: Are there any guarantees in the standard?

(I realize that the issue is not really related to range-based for loops. It's also present when using const_iterators.)

Answer 1

The standard containers all return references from their iterator (note, however, that some "containers aren't really container, e.g., std::vector<bool> which returns a proxy). Other iterators might return proxies or values although this isn't strictly supported.

Of course, the standard doesn't make any guarantees with respect to performance. Any sort of performance related feature (beyond complexity guarantees) are considered to be quality of implementation.

That said, you might want to consider having the compiler make the choice for you as it did before:

for (auto&& e: coll) { f(e); }

The main issue here is that f() may receive a non-const reference. This can be prevented if necessary using a const version of coll.

Answer 2

6.5.4/1 says:

for ( for-range-declaration : braced-init-list ) statement

let range-init be equivalent to the braced-init-list. In each case, a range-based for statement is equivalent to

{
    auto && __range = range-init;
    for ( auto __begin = begin-expr,
                __end = end-expr;
            __begin != __end;
            ++__begin ) {
        for-range-declaration = *__begin;
        statement
    }
}

(further explanation follows of the meanings of all that __ gubbins).

The standard doesn't make any guarantees whether that line const auto &e = *__begin introduces a performance overhead, of course, compared with directly using *__begin instead of e inside statement. Implementations are permitted to implement references by laboriously copying a pointer into some stack slot and then reading it back each time the reference is used, and are not required to optimize.

But there's no reason why there should be an overhead in a sensible compiler, in the case where __begin is a container iterator (whose operator* returns a reference), and then e is passed by value in statement.