Most efficient control condition in a loop

[TheToaster]

There was a multiple choice question on a quiz that asked the following:

The most efficient control condition in a loop is...
a.) a bit
b.) a bool
c.) an integer
d.) a long long integer

I chose b. I assumed this was correct, since any integer value is implicitly converted to bool before evaluation inside a loop anyways. But apparently, the correct answer was "C", an integer. I have no idea why this is. This doesn't seem right to me. Could someone elucidate?

[Manga]

Most of the time when I am making a loop, it looks something like this...

for(int i = 0; i < 3; i++) {
        cout << "Hi there." << endl;
    }

Notice I used an int to control how many times to loop through. An int works well for this purpose.

[Ganado]

In general, it's the other way around. All sizes smaller than an int are converted to an int before arithmetic is applied.

Look at this:

// Example program
#include <iostream>
using std::cout;
int main()
{
    short a = 4;
    short b = 5;
    
    cout << "sizeof(a) = " << sizeof(a) << '\n';
    cout << "sizeof(b) = " << sizeof(b) << '\n';
    cout << "sizeof(a + b) = " << sizeof(a + b) << '\n';
}

2
2
4

a + b is an int, not a short.

That being said, I think it's a slimy question. There doesn't need to be arithmetic happening, so this casting doesn't always apply here. while (true) and while (1) are going be compiled to the same thing. This is only a theoretical issue.

[TheToaster]

@Manga I am aware of how a for loop works. However, In your code, the condition is "i < 3". That is a boolean value. The word "condition" itself implies a boolean. Why should the answer be integer when the condition is clearly a boolean?
And even so, why would an integer be "more efficient"? This seems like a poorly worded question.

[Manga]

I think the question was looking for the dumbed down response. You guys might be over thinking it here.

[Repeater]

Nothing like looking at the generated assembly: https://godbolt.org/z/muoT-_

The colour coding helps. Looks like the control condition checks end up as:

a - a bit
a mov, a test and a jne

b - a bool
a cmp and a jne

c - an int
a mov, a test and a jne

d - a long long int
a cmp and a jne


So they all have a jne, the bit and int have a move + test, the bool and long long just a cmp.

Counting instructions hasn't been a precise science for a long time, but on the face of the generated assembly, the bool and the long long int are equally efficient as the control conditions in the loop.

Who decides the answer was "c - integer" and how did they come to that answer? Did they actually examine the compiled output?

[TheToaster]

Even the "dumbed down" response doesn't make sense. I mean, there is no reason for an integer to be "more efficient" than a bpolean when used as a condition. Compiler-wise, they are going to be compiled to the same thing (as Ganado states), but even if you ignore compiler optimization entirely and assume that a cast has to be done in order for an integer to be in a condition, that would mean that a boolean would be "more" efficient (in the loosest definition of the term) because it requires no cast.

@Ganado, so does the following code deduce the type of c to be an int?

short a = 3, b = 4;
auto c = b+a;

It seems that way. However, what does this have anything to do with control conditions? This seems completely unrelated.

[Manga]

I was looking at your choices... Suppose you want something to loop through many times. A bit is too small, a bool is only true or false so that is two options, and the long long int is overkill. That is my reasoning... :)

[TheToaster]

@Repeater
I believe it is most likely the ancient and incorrect methods taught by my university's introductory programming courses. They still teach exception specifications despite their deprecation since C++11. In any case, from an examination of the generated assembly code it is clear that the writer of this question is wrong.

[jlb]

The reason that C. should be the correct answer is because it is usually considered the "natural" integer for the processor in question. Remember that the "size" of the integral types is implementation defined and the implementation will usually size an int to the processor registers.

Remember a bit and a bool have at most two values, a 0 or a 1, true or false.

A long long integer will not always fit directly in most basic of the processors registers, although it will probably fit in at least 1 or 2 "combined" registers.

[TheToaster]

@jib
But the question is regarding control conditions. All control conditions of a loop are implicitly cast to bool for evaluation. Also, the course teaches nothing about low-level processor implementation, just C++.

Why should while(1){} be any more efficient thanwhile(true){}? Yes, a compiler will generate the exact same code for both, but ignoring any and all compiler optimizations, the int is cast to a bool anyways. As we see from the generated assembly output in Repeater's post above, they are practically equivalent. In which case, the question itself is invalid.

[jlb]

But the question is regarding control conditions.

Yes and control conditions are most often numeric. Look at the for() loop.

All control conditions of a loop are implicitly cast to bool for evaluation.

Not really, remember a bool is basically an integer that has a value of zero and not zero.

Also, the course teaches nothing about low-level processor implementation, just C++.

What? Do you really think that C++ is only a high level language? One of the biggest features of C++ is that is can do low level work.

[Ganado]

However, what does this have anything to do with control conditions

It might not be related, but the connection I was trying to make is similar to what jlb said. I don't know where I first heard this, but apparently CPUs work better with whatever the "natural" sizeof(int) is for that platform. So if you start trying to do things that bigger or smaller than ints, more processing might be needed. Testing a bool input might, say, use the register dil, which is an 8-bit register, but testing an int input might use register edi (which is a 32-bit register).

Of course, Repeater's example shows this often doesn't make a difference, and the compiler will do what it pleases, making the original question a very dubious one.

[TheToaster]

Yes and control conditions are most often numeric. Look at the for() loop.

Control condition for a for loop:
for(/*intialization*/;/*control condition */;/*iteration step/*/)

In particular,
/*control condition (boolean)*/

The control condition is a boolean.

Even if we take your example of a for loop (which is incorrect, since the initialization and the iteration step do not make up the control condition), you still have not shown why that would be more efficient than a boolean. I gave a concrete example of this:
Why should while(1){} be any more efficient thanwhile(true){}?


Yes, I know that a "bool" is an integer type internally, a byte in length. That is not what the question is asking. The question gave 4 concrete options (int, bool, bit, and long long). One of those answers is a bool. The question asks what is the "most efficient" control condition, and as it has been proven here, they are practically equivalent:
https://godbolt.org/z/muoT-_

And even if it wasn't practically equivalent, that the assembly outputs for both radically differ, this still wouldn't matter since the class doesn't teach assembly or low level constructs, so we wouldn't be expected to know that either way.

Not really, remember a bool is basically an integer that has a value of zero and not zero.

As I stated before, this is an implementation detail. Although I am well aware of this fact, this was not covered in our class. Secondly, this statement is irrelevent. Whether a bool is implemented internally as a byte-long integer is irrelevent. To reiterate, the four choices are int, bool, long long, or bit. The question asks NOTHING about the implementation details of the four choices. This is a second-semester programming course.

My response was IGNORING all of these intricacies of implementation details, since first-year coding students aren't going to know about them considering many of them have just learned programming from this course.

What? Do you really think that C++ is only a high level language? One of the biggest features of C++ is that is can do low level work.

Perhaps read my statement again:
Also, the course teaches nothing about low-level processor implementation, just C++

I said that the COURSE doesn't teach the implementation details of C++. This is a first-year beginner's programming course. Also, how did you come to that conclusion that I think C++ is only a high level language? I have used C++ for both high and low level projects, ranging from user software to having to write barebones inline assembly in my C++ code. I am well aware of this fact. But once again, this is irrelevent.

In a beginners programming course, they aren't going to teach you the ins and outs of the Itanium ABI or about compiler optimization techniques. Surely you know this! They will only teach you how to write software in C++, and additional details regarding compilers and assembly language are omitted for future courses. This was the case in my course.

If we ignore compiler optimization and try to put ourselves in the minds of first-year programming student's who know absolutely nothing about programming or assembly language or compilers, we could make a reasonable argument that a bool would be more efficient than an int because of the implicit conversion that has to occur (semantically). This is why I chose "B" even though a broader analysis well beyond the scope of a first year class demonstrates that it is not the case, because I tried to use what was only covered in the course syllabus even though I know more than what the course teaches.

Although, this explanation is wrong, it still makes logical sense for a first-year course that teaches nothing about what goes on under the hood. So "B" would be the most logical incorrect answer for a first-year course. The reason I selected "bool" was because I was trying to put myself in the head of the questioner in the context of a first-year course in programming. However, the questioner made the correct answer "C" which makes absolutely no sense given the constraints of a first-year course.

Now, since you and I can both see the generated assembly output for both are practically the same, we know that it isn't the case. That is the argument I wanted to give to my professor, and I just wanted to confirm this by making a thread about it here.

[TheToaster]

I don't know where I first heard this, but apparently CPUs work better with whatever the "natural" sizeof(int) is for that platform.

That is interesting. Given that this is a beginner's course, however, I strongly doubt that is the answer they were looking for since this is not covered by the course material. It is most likely an error by the questioner, would you not agree?

[jlb]

That is the argument I wanted to give to my professor, and I just wanted to confirm this by making a thread about it here.

Well since, IMO, your argument doesn't hold water good luck.

[TheToaster]

Well since, IMO, your argument doesn't hold water good luck.

How so? Why would an int be more efficient than a bool in a control condition?
Substantiate your argument by using nothing more than what is taught in a first-year programming course (i.e. nothing more than what is taught here: http://www.cplusplus.com/doc/tutorial/ )

My argument is that this question shouldn't EXIST in a first-year course on programming because of its ambiguity of what "efficiency" means in this context, given the course material doesn't cover compiler optimization, assembly, or any other constructs other than the pure semantics of the C++ language. My argument is that it should be eliminated ENTIRELY because of this.

Even in more advanced courses, the question and the correct associated answer doesn't hold any water as we have proved here:
https://godbolt.org/z/muoT-_

If the exact question in the exact wording were given in an advanced course on the matter, it still wouldn't matter, since there was no indication that this was a theoretical issue, and that compiler optimizations should be ignored. Thus, if a student argues in this hypothetical advanced class that the compiler generated assembly output is almost equivalent, that is a valid criticism of the question since the question itself did not elucidate that this is a theoretical issue and the practical compiler generated assembly should be ignored. In both the hypothetical advanced class and the beginner class, the question is ambiguous.

So the question is, as Ganado says, dubious. That, "IMO", is a pretty strong argument.

[mbozzi]

Obviously the answer is int, since the word int has 3 letters and bool has 4. ;)

[deleted account xyzzy]

Good luck trying to convince an instructor and their curriculum is in error.

It sounds like the question and the "correct" answer was written by someone who has very little to no understanding of C/C++.

[TheToaster]

Good luck trying to convince an instructor and their curriculum is in error.

It sounds like the question and the "correct" answer was written by someone who has very little to no understanding of C/C++.

I guess I'll just have to try to make a case for myself. If it doesn't work, then oh well. Such is the pitiable state of modern programming education in most universities.