Auto Type Deduction in C++ Range-Based For Loops • Hacker News Board

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

#21

Post by lorenzhs » Fri, Sep 02, 2016, 4:34 PM UTC

s3rvac wrote: post #20

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.

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.

Thanks, that's clearer.

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

#22

Post by E6300 » Fri, Sep 02, 2016, 4:50 PM UTC

dbaupp wrote: post #16

avlasyuk wrote: post #15

Earlier quoted context omitted.

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.

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

#23

Post by dmoy » Fri, Sep 02, 2016, 4:59 PM UTC

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…

There's definitely a way to abuse it. But if, for instance the type is shown a couple lines up, it's not too bad. E.g. if the for loop is iterating over a var passed into a function.

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

#24

Post by dbaupp » Fri, Sep 02, 2016, 5:34 PM UTC

E6300 wrote: post #22

dbaupp wrote: post #16

Earlier quoted context omitted.

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?

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

#25

Post by gpderetta » Fri, Sep 02, 2016, 6:18 PM UTC

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

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

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

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

#26

Post by clappski » Fri, Sep 02, 2016, 6:19 PM UTC

jschwartzi wrote: post #19

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

I'm currently working on a code base that's just upgrading to MSVC 10.0, and seeing std::vector::value_type(?)::const_iterator everywhere is killing me.

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

#27

Post by E6300 » Fri, Sep 02, 2016, 6:32 PM UTC

dbaupp wrote: post #24

E6300 wrote: post #22

Earlier quoted context omitted.

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.

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

#28

Post by overgard » Fri, Sep 02, 2016, 9:10 PM UTC

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…

With regard to your example, in any decent IDE you can mouse over "auto" and get the type information. However p.first and p.second are obscure and hard to read no matter what your tools do.

I don't get why people seem to think type inference equates to a hatred of static typing. Usually if I'm reading code I want as little clutter as possible, and if I need to know the type it's trivial to find it. I still like that I can know the type of something ahead of time, but I don't need it in my face constantly.