Mfcttrf

Your code is perfectly fine

You are absolutely correct and your teacher is wrong. There is absolutely no reason at all to add that extra complexity, since it does not affect the result at all. It even introduces a bug. (See below)

First, the check if n is zero is obviously completely unnecessary and this is very easy to realize. To be honest, I actually question your teachers competence if he have objections about this. But I guess everybody can have brain farts from time to time.

The second one is a bit more understandable, but he is still wrong.

This is what the C11 standard 6.5.5.p6 says:

If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a; otherwise, the behavior of both a/b and a%b is undefined.

Actually, even C89 says the same and I cannot imagine that you're using an older C-version than that.

And in your case c/n is defined for all c and n. It would only be undefined if n=0 but since n!=0 is the condition for entering the loop, it's fine. According to the standard, this implies that c%n is defined for all c and n.

So there's absolutely nothing wrong with doing modulo with negative numbers. And since you're squaring the result, there is no problem at all.

Your teachers code is flawed

Yes, it actually is. If the input is INT_MIN and the architecture is using two's complement AND if the bit pattern where the sign bit is 1 and all value bits are 0 is NOT a trap value (using two's complement without trap values is very common) then your teachers code will yield undefined behavior. Your code is - if even so slightly - better than his. And considering introducing a small bug by making the code unnecessary complex and gaining absolutely zero value, I'd say that your code is MUCH better.

But then again, your teacher explicitly says that n should be in the range [-(10^7), 10^7]. So that could have saved him, if it were not for the case that int is not necessarily a 32 bit integer. If you compile it for a 16-bit architecture, both of your code snippets are flawed. To avoid this, you can use int32_t instead. Then you will be safe.

EDIT:

As pointed out by Andrew Henle in comments, int32_t is not required by the standard, so to be 100% portable, use int_least32_t or int_fast32_t instead.

A while loop in almost every programming languge checks if the value given by the express is "truthy". In C and C++ "truthy" is defined as non-zero. For the most part although it can different some circumstances while(n) is the same thing as saying while(n != 0) which uses an expression n != 0 that evaluates to either 1 or 0 based on the truth of the expression.

I don't completely like either your version or your teacher's. Your teacher's version does the extra tests that you correctly point out are unnecessary. C's mod operator is not a proper mathematical mod: a negative number mod 10 will produce a negative result (proper mathematical modulus is always non-negative). But since you're squaring it anyway, no difference.

But this is far from obvious, so I would add to your code not the checks of your teacher, but a big comment that explains why it works. E.g.:

/* NOTE: This works for negative values, because the modulus gets squared */

NOTE: AS I was writing this answer, you did clarify that you are using C. The majority of my answer is about C++. However, since your title still has C++ and the question is still tagged C++, I have chosen to answer anyway in case this is still useful to other people, especially since most of the answers I've seen till now are mostly unsatisfactory.

In modern C++ (Note: I don't really know where C stands on this), your professor seems to be wrong on both counts.

First is this part right here:

if (n == 0) 
 return 0;

In C++, this is basically the same thing as:

if (!n) 
 return 0;

That means your while is equivalent to something like this:

while(n != 0) 
 // some implementation

That means since you are merely exiting in your if when the while wouldn't execute anyway, there really isn't a reason to put this if here, since what you are doing after the loop and in the if are equivalent anyway. Although I should say that is for some reason these were different, you'd need to have this if.

So really, this if statement isn't particularly useful unless I'm mistaken.

The second part is where things get hairy:

if (n < 0) 
 n = n * (-1);
 

The heart of the issue is is what the output of the modulus of a negative number outputs.

In modern C++, this seems to be mostly well defined:

The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined. For integral operands the / operator yields the algebraic quotient with any fractional part discarded; if the quotient a/b is representable in the type of the result, (a/b)*b + a%b is equal to a.

And later:

If both operands are nonnegative then the remainder is nonnegative; if not, the sign of the remainder is implementation-defined.

As the poster of the quoted answer correctly points out, the important part of this equation right here:

(a/b)*b + a%b

Taking an example of your case, you'd get something like this:

-13/ 10 = -1 (integer truncation)
-1 * 10 = -10
-13 - (-10) = -13 + 10 = -3 

The only catch is that last line:

If both operands are nonnegative then the remainder is nonnegative; if not, the sign of the remainder is implementation-defined.

That means that in a case like this, only the sign seems to be implementation-defined. That shouldn't be a problem in your case because, because you are squaring this value anyway.

That said, keep in mind that this doesn't necessarily apply to earlier versions of C++, or C99. If that is what your professor is using, that could be why.

EDIT: Nope, I'm wrong. This seems to be the case for C99 or later as well:

C99 requires that when a/b is representable:

(a/b) * b + a%b shall equal a

And another place:

When integers are divided and the division is inexact, if both operands are positive the result of the / operator is the largest integer less than the algebraic quotient and the result of the % operator is positive. If either operand is negative, whether the result of the / operator is the largest integer less than the algebraic quotient or the smallest integer greater than the algebraic quotient is implementation-defined, as is the sign of the result of the % operator. If the quotient a/b is representable, the expression (a/b)*b + a%b shall equal a.

Does either ANSI C or ISO C specify what -5 % 10 should be?

So, yeah. Even in C99, this doesn't seem to affect you. The equation is the same.

What Conner Wallace wrote was correct.

Basically inside,
while ( x ) -- means:
run loop as long as

• x is not 0 or 0.0


• not null


• not end of string terminator ()

that is "x" can be integer, float, char , char *, void * etc... but you can use single form!!

For experienced users, it is easily understandable, convenient instead of comparing to explicit data of each type accordingly.

Also consider simplicity:

int sum(int n) 
int sum=0;

for(int i=1;i<=n;i++) 
 sum += i;

return sum;

`

To :
//Basically same loop backwards, but less elements

int sum(int n) 
 int sum=n;

 while ( n-- ) 
 sum += n;

 return sum;