How are expressions evaluated in Turbo C++?

Question

I was reading about casts in c++ and got confused about how are the expressions actually evaluated. Consider the following code in which var is of type int and after the expression var = (var*10)/10 the memory of var gets overflowed:

#include<iostream.h>

void main()
{
  int var = 25000; // signerd int varies from -32768 to 32767
  var = (var*10)/10; // seems like (var*10) is stored in the memory allocated `var`  
  cout << "Incorrect value of var is:" << var << endl;

  var = (long(var)*10)/10;
  cout << "correct value of var is:" << var << endl;
}

The incorrect value shown is -1214 and the correct is, as expected, 25000. I am very much confused about how is the expressions var = (var*10)/10; actually evaluated. Does the compiler evaluates the expression step by step such that the result of first operation[ (var*10) ] performed on the numeric value of var is stored in it's allocated memory then the value stored in that memory space is used for further operations to be performed.

My knee jerk was that the compiler directly computes the value (var*10) then divides this value with 10 but this doesn't seem to be the case.

So the question is,

• How are expressions, in general and for my specific example, evaluated in C++?

---

P.S: I know that I am using an outdated dialect of C++ language and C++ compiler.

Answer 1

Yes and no. At least in a typical case, the compiler won't store the intermediate results back in the original memory location. It will, however, typically carry out the operation(s) on a register that's the same size, and each intermediate result will be written back to that register. So, for your case, the compiler might generate code something like this:

mov ax, var ; load the value from `var` into register ax
mov bx, 10  ; load 10 into register dx
imul bx     ;  multiply ax * bx. 32-bit result:
            ; 16 least significant bits in AX
            ; 16 most significant bits in DX
xor dx, dx  ; zero dx, in this case losing some significant digits
idiv bx     ; divide ax by bx. 32-bit result:
            ; 16-bit dividend in ax
            ; 16-bit remainder in dx
            ; if dividend won't fit in 16 bits, trigger a "divide by 0" exception
mov var, ax ; store final result back into var's location in memory

Each of these registers (ax, bx, dx, etc.) is 16 bits in size.

When you do the division on a long instead of an int, it does roughly the same thing, but the intermediate will be carried out to 32-bit precision instead of just 16 bit precision.

With a compiler that knew how to generate 32-bit instructions it would come out virtually identical, except that it would replace ax with eax, bx with ebx, and dx with edx. A 16-bit compiler won't know how to generate those instructions though, so it'll normally have to use some library routines to do get 32-bit precision.

Answer 2

How are expressions, in general and for my specific example, evaluated in C++?

Expression evaluation is a bit complex to describe in detail in an answer, so I will focus on your examples.

---

var = (var*10)/10;

In this case, two things may happen. Since the value can be computed at compile-time, the compiler is permitted to perform the calculation the same way it would occur at runtime and store the result directly. Keep in mind that C++ does not specify how anything must occur, it focuses on the results. In other words, the standard basically says "an expression must evaluate to a result using certain semantics," but a compiler is free to precompute, reorder operations, etc. as long as the result is the same.

The other option is the compiler does nothing and the computation occurs at runtime, and this value will overflow and produce undesired results as others have noted.

---

var = (long(var)*10)/10;

This works the same way, except the intermediate values are stored in a long instead of an int which is generally larger (but not required to be).

---

Please note that in both examples any computation at runtime will use intermediate values: only the = operator will store the value in var. Any other values may be stored in temporary variables created by the compiler, registers, or in the brains of nasal demons - the standard lets the compiler do whatever it wants as long as the end result is the same.

Further Reading

I recommend reading up on constexpr. While your ancient compiler does not support it, any discussion of this new keyword will go into more depth on the topics I brought up in this answer.

• Difference between constexpr and const
• const vs constexpr on variables

Answer 3

Does the compiler evaluates the expression step by step such that the result of first operation[ (var*10) ] performed on the numeric value of var is stored in it's allocated memory then the value stored in that memory space is used for further operations to be performed.

Yes.

My knee jerk was that the compiler directly computes the value (var*10) then divides this value with 10 but this doesn't seem to be the case.

I don't see the distinction.

Whether computed at compile-time (thanks, optimiser!) or at run-time, the semantics of var's type still must be adhered to. If it can't hold values higher than 32768, then it can't hold values higher than 32768, and no matter how much magic the compiler performs to run the calculation as quickly as possible, that fact can't and won't change.

Mind you, signed integer overflow is undefined (meaning anything can happen) so I suppose in theory you could see your expected result here, but I wouldn't hold my breath. ;)