0

I tried to refresh my c++ knowledge and found a strange behaviour. When I declared a class and overloaded an operator in it, I forgot that the operator has a return value. This caused some behaviour I cannot explain. Here is the code:

class myClass{
    double i;
    myClass(double value): i(value){}
    myClass operator+ (const double &param)
    {
        i = i + param;
    }
};

So, the operator+ should return a value with type myClass, but instead it just adds param to member i. When I tried this operator in my program by

myClass A(10.5);
A+10.0;

the result is A.i = 20.5, as i would expect. But if I change the code to

A = A + 10.0;

The result is A.i = nan, or some very small number. I realized, that the operator+ should return a value by definition, but I didn't add return to its definition. My question is, what is returned in this case? Some random garbage value from memory? Why does the compiler not enforce to add a return to the operator definition if it is expected to return a value with myClass type?

Fekete Ferenc
  • 119
  • 2
  • 11
  • In short: what you wrote has undefined behavior, the compiler is not required to catch it, and anything at all can happen at runtime. – Mat Feb 19 '14 at 10:46
  • `A+10.0;` should not change members of A, that is what `operator +=` is for! This is just super confusing – stijn Feb 19 '14 at 10:46
  • Yes, it is confusing. First I tried A = A + 10.0, and when I realized that is not working as I expected, then I tried plain A+10.0. I would not use this way my operator, just tried if it works. – Fekete Ferenc Feb 19 '14 at 10:50

3 Answers3

1

The program has undefined behaviour. So it can return anything that is present in the stack.

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
1

Some random garbage value from memory?

Most likely. Formally, as already noted, the behaviour is undefined, so anything is allowed, but most implementations will return some garbage value.

Why does the compiler not enforce to add a return to the operator definition if it is expected to return a value with myClass type?

Because a function that has a return type doesn't need to return at all. There can be good reasons for having functions with a return type that always throw an exception, for example, in which case a diagnostic for a missing return statement is only a hindrance. That could even happen in ways the compiler cannot possibly see, for example when the last statement of the function is a call to another function that doesn't return normally.

Sort of an example:

int negate(int i) {
  if (i >= -INT_MAX)
    return i;

  /* i cannot be negated */
  abort();
}

You might write functions like this to prevent silently going on when INT_MIN is passed, to make debugging easier. In this case, the fact that there is no return statement after abort(); is not a problem. Admittedly, this function does have a return statement, but as far as the compiler knows, it's possible for this function to return by reaching the closing }.

Some compilers do have an option for warning about a missing return statement, so you could try to turn up your warning level.

0

Just a garbage value, you are telling to expect a return value but not actually telling it to return anything.

Eamonn McEvoy
  • 8,876
  • 14
  • 53
  • 83