Hacker News Reader

Comment by randomguy1254 | Hacker News Reader

I use const auto on occasion, when the element type is inexpensive to copy. If I'm iterating over a vector if int's, why would I prefer const auto& over const auto? Assuming the compiler does not try to optimize the const auto&, const auto should be faster than accessing a value through a reference.

View on HN

Using const auto& over const auto makes your code more robust. For example, what if you later decide to change the type of items in the vector from ints to something that is more expensive to copy? You would need to track all uses of the vector and add an ampersand there. And as for the access speed, YMMV but compilers are generally good at optimizations and will drop the reference when it would be faster to just copy the items.

But be careful about the lifetime of the object referenced! Just because its 'const' doesn't mean it cant go out of scope.

Local const reference prolongs the object lifetime[1]. There shouldn't be any problems whenever you use it in a for loop.

[1]: https://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-th...

There definitely can be problems: the reference may escape the for loop, and the reference may be invalidated by a modification of the container (even for something "stable" like ordered_map, the referent may be removed).

If a pointer/reference escapes the loop you'll have problems whether the thing to the right of the colon is a reference or a copy. If it's a copy, the escaped reference will definitely be invalid once that iteration complete. If it's a reference, it will remain valid in more situations.

Yes, I believe that's what I was saying, but your comment sounds like it is disagreeing. Could you clarify?

Oh, okay, then. I thought you were saying that that was a problem specific to iterating by reference.

references prolong the lifetime of temporaries. It wouldn't work in this case:

vector<int> v =...; const auto& x = v[59]; v.clear(); // x is dangling

Good point about robustness, it makes sense in the general case, but if I have a container of integers, I think the chance that I replace int with a more expensive type while not having to modify the rest of the loop is pretty unlikely. Chances are the more expensive type would no longer behave like an int. I think there are cases where the robustness approach shines, and cases where it's pretty safe to just use a const copy and a reference would just add noise. Imagine a simple function where I initialize an array of integers, then iterate over them. const auto or just const int makes sense, const auto& requires more explanation and invoking what if's that are unlikely to ever surface.

Reply on news.ycombinator.com