i = i++ for class types...still undefined?

[DaKoadMunky]

I was recently reading an article about sequence points that used the canonical

i = i++;

as an illustration of modifying a variable multiple times between sequence
points.

Curiously the article did not indicate the type of i.

Is it fair to say that if i was an instance of a class type that overloaded
operator++(int) that we are no longer dealing with undefined behavior?

My reasoning is that in that case

i = i++;

is actually

i.operator=(i.operator++(0));

and i is not really being modified multiple times between sequence points.

Can anyone shed some light on this?

 

[David Hilsee]

I was recently reading an article about sequence points that used the canonical

i = i++;

as an illustration of modifying a variable multiple times between sequence
points.

Curiously the article did not indicate the type of i.

Is it fair to say that if i was an instance of a class type that overloaded
operator++(int) that we are no longer dealing with undefined behavior?

My reasoning is that in that case

i = i++;

is actually

i.operator=(i.operator++(0));

and i is not really being modified multiple times between sequence points.

Can anyone shed some light on this?

It sounds like you don't need any light shed on this. It's true that some
of the undefined behavior that can occur with built-in types does not occur
with class types even when operator overloading makes the code look similar.
In the above code, the function calls create sequence points that would not
be present if i had been of type int, so there is no undefined behavior.
Assuming that i's operator++ and operator= are defined the same as int's,
first the value is incremented and then the old value is passed to
operator=, leaving i unchanged.

 

[Phlip]

I was recently reading an article about sequence points that used the canonical

i = i++;

as an illustration of modifying a variable multiple times between sequence
points.

Curiously the article did not indicate the type of i.

Is it fair to say that if i was an instance of a class type that overloaded
operator++(int) that we are no longer dealing with undefined behavior?

My reasoning is that in that case

i = i++;

is actually

i.operator=(i.operator++(0));

and i is not really being modified multiple times between sequence points.

Nice question.

Can anyone shed some light on this?

I'm not a language lawyer, and I don't play one on teevee...

....But aren't there perforce sequence points inside both i.operator++() and
i.operator=()?

 

[JKop]

DaKoadMunky posted:

My reasoning is that in that case

i = i++;

is actually

i.operator=(i.operator++(0));

and i is not really being modified multiple times between sequence
points.

Can anyone shed some light on this?

Well first thing:

signed main()
{
int i = 5;

i = i++;

std::cout << i;
}

I wouldn't call the above undefined behaviour, more like implementation-
defined behaviour.

signed main()
{
SomeClass obj;

obj = obj++;
}


If obj = obj++ becomes:

obj.operator=( i.operator++(0) );

then you are right in saying that what happens is clearly defined by the
Standard and is not implementation-defined at all.

That's what it looks like to me.


-JKop

 

[Ron Natalie]

I wouldn't call the above undefined behaviour, more like implementation-
defined behaviour.

It's not implementation-defined. The standard doesn't place any restrictions
on what happens here. In fact, most implementations do various things with
that statement based on the context, level of optimization, etc...

 

[Pete Becker]

signed main()
{
int i = 5;

i = i++;

std::cout << i;
}

I wouldn't call the above undefined behaviour, more like implementation-
defined behaviour.

The language definition disagrees with you. The behavior of that code is
undefined.

 

[JKop]

Pete Becker posted:

The language definition disagrees with you. The behavior of that code is
undefined.

With undefined behaviour, anything can happen.

But with the above code, there's but two possibilities:

1) i ends up with the value 5.
2) i ends up with the value 6.

Neither of these possibilities result in undefined
behaviour.

-JKop

 

[Pete Becker]

Pete Becker posted:


With undefined behaviour, anything can happen.

With undefined behavior the language definition imposes no requirements.

But with the above code, there's but two possibilities:

1) i ends up with the value 5.
2) i ends up with the value 6.

Neither of these possibilities result in undefined
behaviour.

The language definition disagrees with you. The behavior is undefined.
Speculating on what a compiler might do doesn't change that.

 

[JKop]

Pete Becker posted:

The language definition disagrees with you. The behavior is undefined.
Speculating on what a compiler might do doesn't change that.

signed main()
{
int i = 5;

i = i++;
}


If we're to be pedantic, then you are right, nothing in particular will
happen in the above.

If we're to be realistic, then I am right, there's two possible things that
may happen.

Overall, you think that you are right and I think that I am right. There's
no more arguments so it look like end of conversation.


-JKop

 

[Pete Becker]

Pete Becker posted:


signed main()
{
int i = 5;

i = i++;
}

If we're to be pedantic, then you are right, nothing in particular will
happen in the above.

Perhaps you have forgotten what you said originally:

I wouldn't call the above undefined behaviour, more like
implementation-defined behaviour.

The terms "undefined behavior" and "implementation defined behavior"
have specific meanings set out in the language definition. When you use
technical terms it is reasonable for people to assume that you intend
them to be interpreted according to their technical meaning. If you do
not intend that, don't use technical terms.

 

[Ron Natalie]

With undefined behaviour, anything can happen.

But with the above code, there's but two possibilities:

1) i ends up with the value 5.
2) i ends up with the value 6.

Neither of these possibilities result in undefined
behaviour.

Both of them are undefined behavior. Implementation
defined behavior means that the implantation is REQUIRED
to tell you which one will happen. No compiler that I know
of ever tells you what i = i++ will return. On most it even
depends on the context. Even if the implementation only
generated one of the above cases, it's under no requirement
to do so consistently.

 

[David Hilsee]

If we're to be pedantic, then you are right, nothing in particular will
happen in the above.

If we're to be realistic, then I am right, there's two possible things that
may happen.

Overall, you think that you are right and I think that I am right. There's
no more arguments so it look like end of conversation.

This is covered in the C FAQ (http://www.eskimo.com/~scs/C-faq/top.html).
See section 3, questions 1 through 9.

 

[Rolf Magnus]

Pete Becker posted:


signed main()
{
int i = 5;

i = i++;
}


If we're to be pedantic, then you are right, nothing in particular
will happen in the above.

You may want to call it "pedantic", but the C++ standard claerly defines
what undefined behavour is and what implementation defined behavour is.
There is no room for interpretation.

If we're to be realistic, then I am right, there's two possible things
that may happen.

The compiler/CPU might also do some special optimziation tricks that
doesn't work correctly without that sequence point (which is actually
the reason for that rule). Do you know _every_ implementation of C++
and are you sure that none of them ever does something else than one of
those two things you think it does?

Overall, you think that you are right and I think that I am right.

Actually, I'm not quite sure whether anyone of you is right, but I know
that you are not
The standard says:

Except where noted, the order of evaluation of operands of indiviual
operators and subexpressions of individual expressions, and the order
in which side effects take place, is unspecified. Between the previous
and next sequence point a scalar object shall have its stored value
modified at most once by the evaluation of an expression. Furthermore,
the prior value shall be accessed only to determine the value to be
stored. The requirements of this paragraph shall be met for each
allowable ordering of the subexpressions for a full expression;
otherwise the bahavor is undefined. [Example:

i = v[i++]; // the behavior is unspecified
i = 7, i++, i++; // i becomes 9

i = ++i + 1; // the behavior is unspecified
i = i + 1; // the value of i is incremented

--end example]

What I don't understand about that is the example. While the actual text
speaks of undefined behavour, the example instead says that it's
unspecified.

There's no more arguments so it look like end of conversation.

This isn't really a matter of opinion.

 

[Bradley Bungmunch]

The language definition disagrees with you. The behavior of that code is
undefined.

Undefined behavior generally refers to erroneous logic. The above is
simply implementation specific, you know.

cf. unspecified behaviors.



=====================



Pussie sHaveMo
reFunMeow MeowMeowPus
siesHaveMore FunMeowMeowMeo
wPussiesHaveMo reFunMeowMeowMeo
wPussiesHaveMor eFunMeowMeowMeowP
ussiesHaveMoreFu nMeowMeowMeowPussi
esHaveMoreFunMeo wMeowMeowPussiesHav
eMoreFunMeowMeowM eowPussiesHaveMor
eFunMeowMeowMeowP ussiesHaveMoreFunM
eowMeowMeowPussie sHaveMoreFunMeowMe owMeowPus
siesHaveM oreFunMeowMeowMe owPussiesHaveMore FunMeowMeowMe
owPussiesHave MoreFunMeowMeowM eowPussiesHaveM oreFunMeowMeowM
eowPussiesHaveM oreFunMeowMeow MeowPussiesHa veMoreFunMeowMeow
MeowPussiesHave MoreFunMeow MeowMeow PussiesHaveMoreFun
MeowMeowMeowPussi esHa veMoreFunMeowMeowMe
owPussiesHaveMoreF unMeowMeowM eowPussiesHaveMoreFu
nMeowMeowMeowPussie sHaveMoreFunMe owMeowMeowPussiesHav
eMoreFunMeowMeowMeo wPussiesHaveMoreFu nMeowMeowMeowPussie
sHaveMoreFunMeowMeo wMeowPussiesHaveMoreFu nMeowMeowMeowPussi
esHaveMoreFunMeowM eowMeowPussiesHaveMoreFu nMeowMeowMeowPuss
iesHaveMoreFunMe owMeowMeowPussiesHaveMoreFu nMeowMeowMeowP
ussiesHaveMor eFunMeowMeowMeowPussiesHaveMore FunMeowMeow
MeowPussi esHaveMoreFunMeowMeowMeowPussiesHave MoreF
unMe owMeowM eowPuss
iesHave MoreF unMeowMeowM
eowPussies Ha veMoreFunMeo
wMeowMeowP us si esHaveMoreFu
nMeowMeowM eow Pus siesHaveMore
FunMeowMeo wMeow Pussi esHaveMoreFu
nMeowMeow MeowPu ssiesH aveMoreFun
Meow MeowMeow Pussie
sHaveMoreFunMeowMeowMeowPussiesHaveM
oreFunMeowMeowMeowPussiesHaveMo
reFunMeowMeowMeowPussies

 

[Bradley Bungmunch]

Perhaps you have forgotten what you said originally:

I wouldn't call the above undefined behaviour, more like
implementation-defined behaviour.

The terms "undefined behavior" and "implementation defined behavior"
have specific meanings set out in the language definition. When you use
technical terms it is reasonable for people to assume that you intend
them to be interpreted according to their technical meaning. If you do
not intend that, don't use technical terms.

You should know.



=====================



Pussie sHaveMo
reFunMeow MeowMeowPus
siesHaveMore FunMeowMeowMeo
wPussiesHaveMo reFunMeowMeowMeo
wPussiesHaveMor eFunMeowMeowMeowP
ussiesHaveMoreFu nMeowMeowMeowPussi
esHaveMoreFunMeo wMeowMeowPussiesHav
eMoreFunMeowMeowM eowPussiesHaveMor
eFunMeowMeowMeowP ussiesHaveMoreFunM
eowMeowMeowPussie sHaveMoreFunMeowMe owMeowPus
siesHaveM oreFunMeowMeowMe owPussiesHaveMore FunMeowMeowMe
owPussiesHave MoreFunMeowMeowM eowPussiesHaveM oreFunMeowMeowM
eowPussiesHaveM oreFunMeowMeow MeowPussiesHa veMoreFunMeowMeow
MeowPussiesHave MoreFunMeow MeowMeow PussiesHaveMoreFun
MeowMeowMeowPussi esHa veMoreFunMeowMeowMe
owPussiesHaveMoreF unMeowMeowM eowPussiesHaveMoreFu
nMeowMeowMeowPussie sHaveMoreFunMe owMeowMeowPussiesHav
eMoreFunMeowMeowMeo wPussiesHaveMoreFu nMeowMeowMeowPussie
sHaveMoreFunMeowMeo wMeowPussiesHaveMoreFu nMeowMeowMeowPussi
esHaveMoreFunMeowM eowMeowPussiesHaveMoreFu nMeowMeowMeowPuss
iesHaveMoreFunMe owMeowMeowPussiesHaveMoreFu nMeowMeowMeowP
ussiesHaveMor eFunMeowMeowMeowPussiesHaveMore FunMeowMeow
MeowPussi esHaveMoreFunMeowMeowMeowPussiesHave MoreF
unMe owMeowM eowPuss
iesHave MoreF unMeowMeowM
eowPussies Ha veMoreFunMeo
wMeowMeowP us si esHaveMoreFu
nMeowMeowM eow Pus siesHaveMore
FunMeowMeo wMeow Pussi esHaveMoreFu
nMeowMeow MeowPu ssiesH aveMoreFun
Meow MeowMeow Pussie
sHaveMoreFunMeowMeowMeowPussiesHaveM
oreFunMeowMeowMeowPussiesHaveMo
reFunMeowMeowMeowPussies

 

[Pete Becker]

otherwise the bahavor is undefined. [Example:

i = v[i++]; // the behavior is unspecified
i = 7, i++, i++; // i becomes 9

i = ++i + 1; // the behavior is unspecified
i = i + 1; // the value of i is incremented

--end example]

What I don't understand about that is the example. While the actual text
speaks of undefined behavour, the example instead says that it's
unspecified.

That has been fixed. The current draft in boht places says that the
behavior is undefined.

 

[Pete Becker]

Undefined behavior generally refers to erroneous logic. The above is
simply implementation specific, you know.

The language definition says that the behavior of that code is
undefined.

 

[DaKoadMunky]

This might be a question for another posting or group, but here goes...

int n = 0;

n = n++; //Undefined due to multiple modifications between SP

If this is undefined why even allow it to compile?

I am aware that not all actions leading to undefined behavior can be caught at
compile-time but in this case it seems that it could.

What is the value in allowing this to be syntatically correct yet saying
anything at all could happen?

 

[Jack Klein]

Pete Becker posted:


With undefined behaviour, anything can happen.

But with the above code, there's but two possibilities:

1) i ends up with the value 5.
2) i ends up with the value 6.

Neither of these possibilities result in undefined
behaviour.

Enough. *plonk*

 

[JKop]

Jack Klein posted:

behaviour.

Enough. *plonk*

Your post is OFF-TOPIC here.

Have you got kids? Did you learn that from them? Or do you
intend to teach it to them?


-JKop