post increment not post

[Robert Swan]

I'd like to know why the following program outputs 1, and not 0.

#include <iostream>

class a {
int v;
public:
a():v(0){}
a& operator++(int) {
v++;
}
operator int&() {
return v;
}
};

int main() {
a aa;
// I intend b to initialize b with 0, then increment a
int b = aa++;
std::cout << b << std::endl;
// didn't happen
}

Thanks,
Robert

[Victor Bazarov]

Robert Swan wrote:

I'd like to know why the following program outputs 1, and not 0.
I am surprised it outputs anything. It's not supposed to compile.

#include <iostream>

class a {
int v;
public:
a():v(0){}
a& operator++(int) {
v++;
This function is defined to have no 'return' statement although one
is required for non-void function which is not a c-tor or d-tor.
It is unknown what you _intended_ to do. The program is ill-formed.
}
operator int&() {
return v;
}
};

int main() {
a aa;
// I intend b to initialize b with 0, then increment a
int b = aa++;
std::cout << b << std::endl;
// didn't happen
}

You need to do something about the operator++, then we can talk.

V

[Ron Natalie]

Robert Swan wrote:

I'd like to know why the following program outputs 1, and not 0.

#include <iostream>

class a {
int v;
public:
a():v(0){}
a& operator++(int) {
v++;

You're missing a return here.
If you return
*this
then, the program should behave like you observed.
The v member is incremented and the side effect applied
before the operator++ returns.

If you want it to behave like a real postincrement, you
need to return a copy of the old object.

a operator++(int) {
a temp(*this);
v++;
return a;
}

[Ron Natalie]

Robert Swan wrote:

operator int&() {
return v;
}

By the way, returning a reference here is probably a bad idea.

[Robert Swan]

Victor Bazarov wrote:
....

I am surprised it outputs anything. It's not supposed to compile.
It did. However, if I had enabled warnings the compiler would have
revealed the inept code.

#include <iostream>

class a {
int v;
public:
a():v(0){}
a& operator++(int) {
v++;

This function is defined to have no 'return' statement although one
is required for non-void function which is not a c-tor or d-tor.
It is unknown what you _intended_ to do. The program is ill-formed.

Oops. I intended to define class a's post operator ++ to increment
member v, then return a reference to the "invokee object" (not sure what
you're supposed to call it).

I was then thinking the statement

int b = aa++;

should be equivalent to

b = aa; a++;

Seems that it's not.

#include <iostream>

class a {
int v;
public:
a():v(0){}
a& operator++(int) {
v++;
return *this;
}
operator int&() {
return v;
}
};

int main() {
a aa;
// I intend to initialize b with 0, then increment a
int b = aa++;
std::cout << b << std::endl;
// didn't happen
}

[Victor Bazarov]

Ron Natalie wrote:

Robert Swan wrote:

operator int&() {
return v;
}

By the way, returning a reference here is probably a bad idea.

Nah... However, I'd add

operator int() const { return v; }

to boot.

V

[Victor Bazarov]

Robert Swan wrote:

Victor Bazarov wrote:
...

I am surprised it outputs anything. It's not supposed to compile.

It did. However, if I had enabled warnings the compiler would have
revealed the inept code.

I am not sure what 'inept' is in this case. If your compiler allows
the code to compile, the compiler is non-compliant.

#include <iostream>

class a {
int v;
public:
a():v(0){}
a& operator++(int) {
v++;

This function is defined to have no 'return' statement although one
is required for non-void function which is not a c-tor or d-tor.
It is unknown what you _intended_ to do. The program is ill-formed.

Oops. I intended to define class a's post operator ++ to increment
member v, then return a reference to the "invokee object" (not sure what
you're supposed to call it).

We call it (*this).

I was then thinking the statement

int b = aa++;

should be equivalent to

b = aa; a++;

Seems that it's not.

#include <iostream>

class a {
int v;
public:
a():v(0){}
a& operator++(int) {
v++;
return *this;
}
If the operator++ is written that way, its implementation is not as
intended. The built-in operator++(int) first of all returns an r-value
and second, the value is _before_ the increment. If you make it return
a&, it's not an r-value, and if you 'return *this', by the time the
caller gets the value, the object has already been changed.

See Ron's reply for the "correct" and the intended implementation.
operator int&() {
return v;
}
};

int main() {
a aa;
// I intend to initialize b with 0, then increment a
int b = aa++;
std::cout << b << std::endl;
// didn't happen
}

V

[Andrey Tarasevich]

Robert Swan wrote:

I was then thinking the statement

int b = aa++;

should be equivalent to

b = aa; a++;

Seems that it's not.
...

It never is. In your case it is equivalent to

int b = aa.operator++(0 );

It will do whatever you do inside your 'a::operator++' . It will
initialize 'b' with whatever you return from your 'a::operator++' .

You want 'b' to have the old "value" of 'aa'? Then it is your
responsibility to preserve and return that old value from
'a::operator++' . You didn't do that, hence the result.

--
Best regards,
Andrey Tarasevich

[Pete Becker]

Victor Bazarov wrote:

Robert Swan wrote:

Victor Bazarov wrote:
...

I am surprised it outputs anything. It's not supposed to compile.

It did. However, if I had enabled warnings the compiler would have
revealed the inept code.

I am not sure what 'inept' is in this case. If your compiler allows
the code to compile, the compiler is non-compliant.

The requirement in the standard isn't that strong. 6.6.3/3: "....
Flowing off the end of a function is equivalent to a return with no
value; this results in undefined behavior in a value-returning
function." Since the behavior is undefined, no diagnostic is required. A
warning is helpful, except that in more complicated functions compilers
often give erroneous warnings.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Victor Bazarov]

Pete Becker wrote:

Victor Bazarov wrote:

Robert Swan wrote:

Victor Bazarov wrote:
...
I am surprised it outputs anything. It's not supposed to compile.


It did. However, if I had enabled warnings the compiler would have
revealed the inept code.

I am not sure what 'inept' is in this case. If your compiler allows
the code to compile, the compiler is non-compliant.

The requirement in the standard isn't that strong. 6.6.3/3: "....
Flowing off the end of a function is equivalent to a return with no
value; this results in undefined behavior in a value-returning
function." Since the behavior is undefined, no diagnostic is required. A
warning is helpful, except that in more complicated functions compilers
often give erroneous warnings.

Thank you for the correction, Pete. Not ill-formed, just having undefined
behaviour. Got it.

V