C++ for loop

[Spev]

I need help understanding what exactly this for loop does.

I'm used to seeing for loops like this: for (initialization; condition; increase) statement;

 

        for (auto & hash : hash)
            {
                hash.clear();
            }

hash is a hash table by the way. I also need a little help understanding auto, but as far as I know it's just automatically determines the type needed. 

[BlueChinchillaEatingDorito]

If it's similar to how Java works. It's a for each loop. So for each Hash object in hash

[Spev]

Just now, BlueChinchillaEatingDorito said:

If it's similar to how Java works. It's a for each loop. So for each Hash object in hash

I've never coded in Java but I've heard of for each. Basically it just goes through every element in the hash table? I guess that makes sense. I'm using separate chaining so my buckets are linked lists, and my hash table is a vector. So I guess it goes through every element (linked list) in my vector (hash table) and clears the entire list since it's an STL list it's pretty easy. Ok thanks if it's that simple than that explains it.

[BlueChinchillaEatingDorito]

1 minute ago, Spev said:

I've never coded in Java but I've heard of for each. Basically it just goes through every element in the hash table? I guess that makes sense. I'm using separate chaining so my buckets are linked lists, and my hash table is a vector. So I guess it goes through every element (linked list) in my vector (hash table) and clears the entire list since it's an STL list it's pretty easy. Ok thanks if it's that simple than that explains it.

If you know C++, then you should be able to read Java code and know what's going on.

But yea, same thing in Java

For(Object temp : objects){
	//do something
}

Where objects is an object (element in C++ terms) is inerrable. It goes through every Object class object in objects, refers each as temp in each iteration of the loop, and you do whatever you need to do with it.   

[Spev]

25 minutes ago, BlueChinchillaEatingDorito said:

If you know C++, then you should be able to read Java code and know what's going on.

But yea, same thing in Java

For(Object temp : objects){
	//do something
}

Where objects is an object (element in C++ terms) is inerrable. It goes through every Object class object in objects, refers each as temp in each iteration of the loop, and you do whatever you need to do with it.   

I think that explains it enough for now. I'll have to look up some more about for each loops later but it seems simple enough. I've just not been exposed to them really yet apparently in either language. Thanks for the help brother.

[Unimportant]

4 hours ago, Spev said:

I need help understanding what exactly this for loop does.

I'm used to seeing for loops like this: for (initialization; condition; increase) statement;

 

        for (auto & hash : hash)
            {
                hash.clear();
            }

hash is a hash table by the way. I also need a little help understanding auto, but as far as I know it's just automatically determines the type needed. 

Important to add, auto deduces the type, but the ampersand "&" makes it a reference. That means you're working on the element itself, without it you'd be working on a copy and any changes made would not carry over to the actual element in the sequence.

 

The variable names in this snippet are poorly chosen, the element name "hash" hides the sequence name "hash" inside the loop body. Name hiding is generally considered bad because it's confusing and thus leads to bugs. One should prefer something like this:

	//Just an example, the actual names I'd choose depend on the context.	
	for (auto & hash : hashTable)
   	{
    		hash.clear();
  	}

 

 

[Pinguinsan]

6 hours ago, Unimportant said:

The variable names in this snippet are poorly chosen, the element name "hash" hides the sequence name "hash" inside the loop body. Name hiding is generally considered bad because it's confusing and thus leads to bugs. One should prefer something like this:

Would that even compile?

#include <unordered_map>
#include <random>
#include <iostream>

template <typename Numeric, typename Divisor>
inline constexpr bool isDivisibleBy(Numeric numeric, Divisor divisor)
{
    return ((numeric >= divisor) && ((numeric % divisor) == 0));
}

constexpr auto isEven = [](int test) -> bool { return isDivisibleBy<int, int>(test, 2); };

int main()
{
    std::mt19937 randomEngine{std::random_device{}()};
    std::uniform_int_distribution<int> randomDistribution{0, 100};
    std::unordered_map<int, bool> hash{};
    for (int i = 0; i < 10; i++) {
        int randomNumber{randomDistribution(randomEngine)};
        hash.emplace(randomNumber, isEven(randomNumber));
    }
    for (auto &hash : hash) {
        std::cout << "key \"" << hash.first << "\" is " << (hash.second ? "even" : "odd") << std::endl;
    }
    return 0;
}

Pingu@Z170A-Titanium-PC:~$ g++ -Wall -std=c++14 -o test test.cpp
test.cpp: In function ‘int main()’:
test.cpp:16:23: error: use of ‘hash’ before deduction of ‘auto’
     for (auto &hash : hash) {
                       ^

Whoa, here's some weird stuff. As seen above , it fails to compile for g++ 5.4.0, but a live example here compiles. I wonder what compiler version ideone uses?

EDIT: I tried it on my Arch box and g++ 6.3.1 compiles and runs without error.

[Pinguinsan]

You can break down a "range based for loop" in C++ like this:

Consider a list of some type in C++:

std::vector<int> intList{0, 1, 2, 3, 4, 5, 6,  7, 8, 9}; //List of integers, containing 0 through 9

A common range-base-for loop would look like this:

for (auto &it : intList) {
	std::cout << it << std::endl; //Print each item in the list to stdout, followed by a newline (std::endl)
}

The usage of "auto" in the loop just means the C++ compiler will do pattern matching to infer the type, and if it cannot (because it it ambiguous), will issue a compiler error. In this case, it's very simple for the compiler to see that the argument on the right (intList) is a list of integers, so it deduces the type of the variable "it" to be int. The ampersand (&) tells the compiler that you want "it" to be a reference to the items in intList, not a copy (they reference the same value, so a change it it will change the item in the list). Broken down to a simpler for loop, it would look like this (a little bit of pseudocode):

for (int i = 0; i < intList.size(); i++) {
	int &it = &intList.at(i) //Create a reference variable named it that points to the ith item in intList (note the second ampersand)
	std::cout << it << std::endl;
}

If the right side argument were a hash table (as mentioned in the OP), the it would be deduces differently. Generally, a std::unordered_map is implemented as a hash map, so that is a common usage. In that case, if the hash map were of some types TKey and TValue, it would be deduced to be of type std::pair<TKey, TValue> (a pair of types TKey and TValue).

[Unimportant]

1 hour ago, Pinguinsan said:

Would that even compile?

#include <unordered_map>
#include <random>
#include <iostream>

template <typename Numeric, typename Divisor>
inline constexpr bool isDivisibleBy(Numeric numeric, Divisor divisor)
{
    return ((numeric >= divisor) && ((numeric % divisor) == 0));
}

constexpr auto isEven = [](int test) -> bool { return isDivisibleBy<int, int>(test, 2); };

int main()
{
    std::mt19937 randomEngine{std::random_device{}()};
    std::uniform_int_distribution<int> randomDistribution{0, 100};
    std::unordered_map<int, bool> hash{};
    for (int i = 0; i < 10; i++) {
        int randomNumber{randomDistribution(randomEngine)};
        hash.emplace(randomNumber, isEven(randomNumber));
    }
    for (auto &hash : hash) {
        std::cout << "key \"" << hash.first << "\" is " << (hash.second ? "even" : "odd") << std::endl;
    }
    return 0;
}

Pingu@Z170A-Titanium-PC:~$ g++ -Wall -std=c++14 -o test test.cpp
test.cpp: In function ‘int main()’:
test.cpp:16:23: error: use of ‘hash’ before deduction of ‘auto’
     for (auto &hash : hash) {
                       ^

Whoa, here's some weird stuff. As seen above , it fails to compile for g++ 5.4.0, but a live example here compiles. I wonder what compiler version ideone uses?

EDIT: I tried it on my Arch box and g++ 6.3.1 compiles and runs without error.

According to paragraph 6.5.4 of the standard, this range based for loop is equivalent to:

{
   auto && __range = hash; //outer hash as inner hash has not yet been defined, no conflict.
   for (auto __begin = __range.begin(), __end = __range.end(); __begin != __end; ++__begin ) 
   {
       auto & hash = *__begin; //fresh definition of inner hash inside it's own scope, hides outer hash as per normal rules.

       hash.clear();
   }
}

So it should work, but there's enough rope to hang yourself without silliness like this.

[Unimportant]

5 hours ago, Pinguinsan said:

 

template <typename Numeric, typename Divisor>
inline constexpr bool isDivisibleBy(Numeric numeric, Divisor divisor)
{
    return ((numeric >= divisor) && ((numeric % divisor) == 0));
}

constexpr auto isEven = [](int test) -> bool { return isDivisibleBy<int, int>(test, 2); };

 

Just as a interesting FYI for those who care:

One should be able to write:

isDivisibleBy(test, 2);

Template type deduction should do the rest and remove the need for the explicit <int, int>.

[stmfd sp!, {lr}]

15 hours ago, Pinguinsan said:

If the right side argument were a hash table (as mentioned in the OP), the it would be deduces differently. Generally, a std::unordered_map is implemented as a hash map, so that is a common usage. In that case, if the hash map were of some types TKey and TValue, it would be deduced to be of type std::pair<TKey, TValue> (a pair of types TKey and TValue).

Important note:

It will actually deduce: std::pair<const TKey, TValue>.

 

Which is another way that auto will save your ass. Since, if you used a range-based for loop with a map declared with, say, std::map<int, char> and tried to iterate it with a const reference to std::pair<int, char>, each iteration will produce a copy since the constness cast will be implicit. That's why using auto is a nice way to avoid situations where code that looks intuitive will actually produce implicit casts (and, therefore, copies).

 

Sorry for being pedantic.