Auto Type Deduction in C++ Range-Based For Loops
blog.petrzemek.net
Auto Type Deduction in C++ Range-Based For Loops
1–10 of 28 posts
Re: Auto Type Deduction in C++ Range-Based For Loops
#2I don't like that at all.
Sure if you consider:
for (auto& p : wordCount) {
// ... word: p.first, count: p.secondthen
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 information but most of the time you deal with user defined types where that information is a) not clear and b) not as trivial.
To me this whole "auto" thing seems misunderstood. People use it to make their lifes "easier" (think lazy) but not simpler. The type system is there to help you and type information is of uttermost importance and should be available as closest to the usage as possible without destroying readability so you don't have to look it up somewhere else.
using wcPair = std::pair;
for (wcPair& p : wcMap) {
std::cout seems reasonable enough. The loop itself can be read without clutter, you can infer what's supposed to happen without knowing much stuff and even if you want a deeper understanding of what's going on then the information you need is right above.
Doesn't that seem much better? oO
...and if you want a language without a type system don't use a language with a type system.
Re: Auto Type Deduction in C++ Range-Based For Loops
#3Huh, I always thought that there is an optimization to always choose the most consty and referency option possible. So if you write `auto` but don't modify the item in the loop, it may choose to use a reference / pointer under the hood, as if you wrote `auto &` or `const auto &`. But it can't strip away the `&`.
The reason is that I imagined C++ can substitute anything for auto, so it can make `auto` into a pointer to Foo, but it can't turn `auto &` into `Foo`. (In a first pass, of course due to the as-if rule the compiler can do whatever it wants when you are not looking.)
In the example the author reccommends against, `for (const auto x : range)`, I would think it means:
- const: don't let me modify x (enforce const-correctness at compile time)
- Make a copy or reference, whatever is faster.
Particularly, I think/thought: `const` does not tell the compiler to make a copy. The lack of `&` allows the compiler to make a copy.
I'm sure this interpretation is not 100% what's in the standard, but a intuition I developed from observation, so probably some of it is wrong.
Re: Auto Type Deduction in C++ Range-Based For Loops
#4Huh, I always thought that there is an optimization to always choose the most consty and referency option possible. So if you write `auto` but don't modify the item in the loop, it may choose to use a reference / pointer under the hood, as if you wrote `auto &` or `const auto &`. But it can't strip away the `&`. The reason is that I imagined C++ can substitute anything for auto, so it can make `auto` into a pointer t…
auto doesn't mean "make a copy or reference, whatever is faster". auto first and foremost means "make a copy". Then sometimes compilers can do a trick called copy-elision and you might be working on a reference. But generally assume it's going to be a copy.
auto& means only make a reference.
Re: Auto Type Deduction in C++ Range-Based For Loops
#5I 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…
>...and if you want a language without a type system don't use a language with a type system.
I wasn't the one who downvoted you but I'm guessing it happened because your advice is misguided and it shows how you're confusing the ceremony of a human bashing extra keystrokes to repeat annotations everywhere with the concept of static typing that enables compiler correctness checking. The keyword "auto" enables the separation of those 2 concepts. Type inferencing and type deduction is the technology that gives you "types" without the tedious "ceremony".
Re: Auto Type Deduction in C++ Range-Based For Loops
#6Wouldn't one want to use 'f(std::forward(x))' with 'auto&&' ?
Re: Auto Type Deduction in C++ Range-Based For Loops
#7I 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.
Re: Auto Type Deduction in C++ Range-Based For Loops
#8Wouldn'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.
Re: Auto Type Deduction in C++ Range-Based For Loops
#9I 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 experience of other language communities is: you'll get used to it. When C# introduced its version of this with the 'var' keyword many felt that code would become less clear but, in general, context gives you what you need. If it doesn't that often means that there are other problems.
I don't know if this is true in your case, but often people who object haven't spent much time working in dynamically typed languages. The readability issue is orthogonal to typing and it tends to be fine.
Re: Auto Type Deduction in C++ Range-Based For Loops
#10I 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 copy the items.