Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Auto Type Deduction in C++ Range-Based For Loops

blog.petrzemek.net

Post reply on HN
Print view View original

11–20 of 28 posts

Re: Auto Type Deduction in C++ Range-Based For Loops

#11

Post by JoeAltmaier »

s3rvac wrote: post #10
randomguy1254 wrote: post #7

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.

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 cop…

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

Re: Auto Type Deduction in C++ Range-Based For Loops

#12

Post by randomguy1254 »

s3rvac wrote: post #10
randomguy1254 wrote: post #7

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.

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 cop…

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.

Re: Auto Type Deduction in C++ Range-Based For Loops

#13

Post by maxlybbert »

creed wrote: post #2

I don't like that at all. Sure if you consider: for (auto& p : wordCount) { // ... word: p.first, count: p.second } then for (auto& [word, count] : wordCount) { // C++1z // ... } seems like an improvement because you immediately know the semantics of the two parts of the pair. But you have no idea what "word" or "count" is . In this example with words like "word" or "count" the semantics somehow encode type informati…

  > if you consider:
  >
  > for (auto& p : wordCount) {
  > ...
  > But you have no idea what "word" or "count" *is*.
If you know what wordCount is, you'll know what types word and count are.

I remember back when I was still a very new programmer I somehow got the syntax for an iterator-based loop wrong ("for std::vector::iterator itor = v.begin(); itor != v.end(); ++itor)"). I don't remember my mistake. I probably missed a const somewhere. The compiler told me that "std::vector::iterator" did not match the type of v.begin(), but it wouldn't tell me what would match. Even as a beginning programmer, I knew the compiler knew, but all it would say was "you got it wrong."

And, of course, I didn't care what the type of v.begin() was. All I cared about was whether I could iterate over the elements of v. And I knew that v contained int's.

Many programmers learned about strong typing ( https://en.wikipedia.org/wiki/Strong_and_weak_typing ) and static typing ( https://en.wikipedia.org/wiki/Type_system#STATIC ) in languages that require manifest typing ( https://en.wikipedia.org/wiki/Manifest_typing ), so they often don't realize those are three distinct ideas. You can write strongly typed programs in Haskell, Ocaml, Go and Rust without many type statements.

Re: Auto Type Deduction in C++ Range-Based For Loops

#14

Post by sseagull »

lorenzhs wrote: post #8
jmaschad wrote: post #6

Wouldn't one want to use 'f(std::forward(x))' with 'auto&&' ?

I think the example with function application is a bad one here - moving the element potentially leaves it in an undefined state. It would be a better example if the code did something with x instead of calling a function on it. So I don't think you'd want to forward it. Note that you also need the element's type to forward it, which isn't possible in general with the example's signature.

This has been slightly confusing to me, but the syntax auto&& might not mean an rvalue reference. According to the post, it means a universal reference. I wish they would have made a different syntax. For example, with templates, my understanding is:

void somefunction(int && i) // i is an rvalue reference

template void somefunction2(T && i) // i is a universal reference

It might be a similar thing with auto&&. So I would tentatively agree that std::forward should be used.

Re: Auto Type Deduction in C++ Range-Based For Loops

#15

Post by avlasyuk »

JoeAltmaier wrote: post #11
s3rvac wrote: post #10

Earlier quoted context omitted.

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 cop…

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...

Re: Auto Type Deduction in C++ Range-Based For Loops

#16

Post by dbaupp »

avlasyuk wrote: post #15
JoeAltmaier wrote: post #11

Earlier quoted context omitted.

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).

Re: Auto Type Deduction in C++ Range-Based For Loops

#17

Post by lorenzhs »

sseagull wrote: post #14
lorenzhs wrote: post #8

Earlier quoted context omitted.

I think the example with function application is a bad one here - moving the element potentially leaves it in an undefined state. It would be a better example if the code did something with x instead of calling a function on it. So I don't think you'd want to forward it. Note that you also need the element's type to forward it, which isn't possible in general with the example's signature.

This has been slightly confusing to me, but the syntax auto&& might not mean an rvalue reference. According to the post, it means a universal reference. I wish they would have made a different syntax. For example, with templates, my understanding is: void somefunction(int && i) // i is an rvalue reference template void somefunction2(T && i) // i is a universal reference It might be a similar thing with auto&&. So I w…

Yes in this case it's a universal reference, I'm aware. Universal references work with auto&&. What std::forward does is the following:

- if you put in an rvalue reference, it's like std::move

- if you put in anything else, it does nothing.

So my point about the article's formulation ("when you want to modify elements in the range in generic code") and its example remains.

Re: Auto Type Deduction in C++ Range-Based For Loops

#18

Post by catnaroek »

creed wrote: post #2

I don't like that at all. Sure if you consider: for (auto& p : wordCount) { // ... word: p.first, count: p.second } then for (auto& [word, count] : wordCount) { // C++1z // ... } seems like an improvement because you immediately know the semantics of the two parts of the pair. But you have no idea what "word" or "count" is . In this example with words like "word" or "count" the semantics somehow encode type informati…

Static typing doesn't always require type annotations. Type inference is 1970's era technology.

Re: Auto Type Deduction in C++ Range-Based For Loops

#19

Post by jschwartzi »

creed wrote: post #2

I don't like that at all. Sure if you consider: for (auto& p : wordCount) { // ... word: p.first, count: p.second } then for (auto& [word, count] : wordCount) { // C++1z // ... } seems like an improvement because you immediately know the semantics of the two parts of the pair. But you have no idea what "word" or "count" is . In this example with words like "word" or "count" the semantics somehow encode type informati…

The purpose of the type system in C++ is partly to encode semantics about the usage of a particular construct. For example, we might declare three or four types which all support the increment() function(or operator). The traditional way to do this is to create an interface and have the four concrete types inherit from the interface.

What auto says is "I don't care what type this value is. I just want it to support the semantics that I'm about to describe in this block." If you change the return type of the value in the auto expression, as long as the new return type supports the same semantics as the original return type, you don't need to touch that function after the refactor.

The compiler still complains when it can't find a way to make the return value support the semantics you're asking for. This is an improvement, but only in cases where you genuinely don't care what type it is, but only that it supports iteration. You still have to use auto with care, like every other keyword, but it does significantly improve maintainability in code bases where traditionally you would mechanically key in the same type information multiple times throughout the declaration of a class and its usage. Typedef and using statements solve similar problems, but they don't solve exactly the same problem.

For a good example of why this is a wonderful thing, try to determine what return type you should declare for an STL iterator, or try using Boost while avoiding the auto keyword.

Re: Auto Type Deduction in C++ Range-Based For Loops

#20

Post by s3rvac »

lorenzhs wrote: post #8
jmaschad wrote: post #6

Wouldn't one want to use 'f(std::forward(x))' with 'auto&&' ?

I think the example with function application is a bad one here - moving the element potentially leaves it in an undefined state. It would be a better example if the code did something with x instead of calling a function on it. So I don't think you'd want to forward it. Note that you also need the element's type to forward it, which isn't possible in general with the example's signature.

I have improved the example in the article to make the code less confusing. Now, a value is assigned to each element in the range and there is no function call.
Post reply on HN