Size_t Weird Bug within Loop

[exterminator]

The only thing "completely wrong" in the OP's code is his decision to use an unsigned counter.

That is not so wrong after all. The size_type typedefs over the standard containers and sequences are unsigned types as well. Most implementations will have std::size_t and size_type to be the same (but it may not be guaranteed - I am not sure). Both are unsigned integral types - that's for sure.

So, there's nothing inherently wrong with using that kind of a loop. The only thing wrong is that he unknowingly expects that when his loop counter reaches 0, and is decremented, it will become less than 0 and hence break out of the loop. That is wrong!

Although, alternatives have been provided, here is a fix to that loop:

	for (std::size_t loop = obj.size() - 1; loop < obj.size() ; --loop)
	{
		std::cout << obj[loop] << "\n";
	}

[GCDEF]

That is not so wrong after all. The size_type typedefs over the standard containers and sequences are unsigned types as well. Most implementations will have std::size_t and size_type to be the same (but it may not be guaranteed - I am not sure). Both are unsigned integral types - that's for sure.

So, there's nothing inherently wrong with using that kind of a loop. The only thing wrong is that he unknowingly expects that when his loop counter reaches 0, and is decremented, it will become less than 0 and hence break out of the loop. That is wrong!

Although, alternatives have been provided, here is a fix to that loop:

	for (std::size_t loop = obj.size() - 1; loop < obj.size() ; --loop)
	{
		std::cout << obj[loop] << "\n";
	}

Which is why I said that's what's wrong. He's expecting loop to go negative and it can't. For a lot of loops, unsigned is fine. That's obviously not the case here.

[TheCPUWizard]

Although, alternatives have been provided, here is a fix to that loop:

	for (std::size_t loop = obj.size() - 1; loop < obj.size() ; --loop)
	{
		std::cout << obj[loop] << "\n";
	}

Functional but IMHO ugly...I had to look at it three times before concluting that it was correct.

[GCDEF]

Functional but IMHO ugly...I had to look at it three times before concluting that it was correct.

I agree. While functional, that's not an intuitive solution. Using a signed counter makes much more sense to me.

[exterminator]

I agree. While functional, that's not an intuitive solution. Using a signed counter makes much more sense to me.

While the solution may be not as readable as some of the other alternatives (which is not my point actually), using a signed loop counter is unsafe and probably even cause wrong results in certain cases when used with containers like std::vector when the size reaches the upper max limit of that signed type (and still be very far from the upper max limit for the corresponding unsigned type). That is probably the reason why the internal size type used for a vector is exposed as a typedef for the user of the container to use it rather than using any other type of their choice. I, sometimes, have to deal with such huge numbers in my containers, so I consider it to be a rule for me (and theoretically the correct thing to do) rather than just a good practice. So, be it an ugly loop or not, I would not suggest using a signed type to loop over the standard vector.

There is a size_type (which I think is equivalent to size_t) typedef which specifically tells about the type which should be used in context of size and looping as well for those containers. That was all what I wanted to point out.

[TheCPUWizard]

<snip>using a signed loop counter is unsafe and probably even cause wrong results in certain cases when used with containers like std::vector when the size reaches the upper max limit of that signed type (and still be very far from the upper max limit for the corresponding unsigned type).</snip>

No disagreement there. which is why I would choose either the iterator based solution, or one which did not expose the "wrap around" effect [which is mandated by the STD!] such as the post decrement that was previously used.