5 ms·

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 some

by s3rvac 10y ago

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.

JoeAltmaier 10y ago
But be careful about the lifetime of the object referenced! Just because its 'const' doesn't mean it cant go out of scope.
- avlasyuk 10y ago
  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-the-most-important-const/ https://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-th...
  - gpderetta 10y ago
    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
  - dbaupp 10y ago
    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).
    - E6300 10y ago
      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.
      - dbaupp 10y ago
        Yes, I believe that's what I was saying, but your comment sounds like it is disagreeing. Could you clarify?
        E6300 10y ago
        Oh, okay, then. I thought you were saying that that was a problem specific to iterating by reference.
randomguy1254 10y ago
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.

by s3rvac 10y ago

JoeAltmaier 10y ago

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

avlasyuk 10y ago
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-the-most-important-const/ https://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-th...
- gpderetta 10y ago
  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
- dbaupp 10y ago
  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).
  - E6300 10y ago
    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.
    - dbaupp 10y ago
      Yes, I believe that's what I was saying, but your comment sounds like it is disagreeing. Could you clarify?
      - E6300 10y ago
        Oh, okay, then. I thought you were saying that that was a problem specific to iterating by reference.

randomguy1254 10y ago

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.