Some questions about ++ operator

[eulo...@live.com]

1.about ++s:

int s(0);

++++s;

++s=10;

Are they undefined behaviors?

But if s is a "bigint" not a "int", they are well defined.

2.about s++:

Can we understand s++ as:

{

T temp(s);

++s;

return temp;

}

As I have found a question:

#include<stack>
#include<vector>

int main()
{
 std::stack<int,std::vector<int>> stack;
 stack.emplace(3);
 for(int i(0);i!=10000;++i)
  stack.emplace(stack.top()++);                            //UB??
 return 0;
}

My understand on:

  stack.emplace(stack.top()++);

is

{

  auto temp(stack.top());

  ++stack.top();

  stack.emplace(temp);

}

.

For I have tried on G++,CLANG++,VC++, They all work as I think.

Am I right?

If stack is a std::stack<bigint,std::vector<bigint>> stack; not a std::stack<int,std::vector<int>>; I'm sure that it works as I think.

int main()
{
 std::stack<bigint,std::vector<bigint>> stack;
 stack.emplace(3);
 for(int i(0);i!=10000;++i)
  stack.emplace(stack.top()++);                            //I am sure that it's not a UB.
 return 0;
}

If they are UBs, should we expressed them correctly?

[eulo...@live.com]

Some people tell me that internal types don't work like class-types.

在 2013年12月21日星期六UTC+8下午12时37分34秒，eulo...@live.com写道：

[Billy O'Neal]

1. ++++s is ill formed; ++ can only be applied to an lvalue. ++s = 10 is undefined behavior because the write to s as part of ++ and the write assigning s to 10 are unsequenced. For instance, a compiler could add 1 to s and store the result in a register, then assign 10 to s, then assign the register contents of the register to s. (Result: s = s + 1) The compiler could also add 1 to s, store the result back to s, and then assign 10 to s. (Result: s == 10). (Of course, undefined behavior means more than this, but these are the most likely actual behaviors by an actual compiler)

2. No. That is semantically what occurs, but a compiler is under no obligation to actually do the operations in that order. (If it were done as separate statements, the compiler would have no freedom to reorder here)

3. stack.emplace(stack.top()++); is well defined because the evaluation of function arguments is sequenced before the execution of a function. Therefore, the ++ must occur before the emplacement (at least as far as observable behavior of the program is concerned). See N3691 1.9 [intro.execution]/15:

When calling a function (whether or not the function is inline), every value computation and side effect

associated with any argument expression, or with the postfix expression designating the called function, is

sequenced before execution of every expression or statement in the body of the called function.

Billy O'Neal

https://github.com/BillyONeal/

http://stackoverflow.com/users/82320/billy-oneal

Malware Response Instructor - BleepingComputer.com

--
 
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposal...@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

[Billy O'Neal]

Ah, scratch what I said in #1 -- it is ill-formed in C but well-formed in C++. It still causes undefined behavior in this case though :)

Billy O'Neal

https://github.com/BillyONeal/

http://stackoverflow.com/users/82320/billy-oneal

Malware Response Instructor - BleepingComputer.com

[wsdwsd]

1. ++++s is ill formed.

I think it’s no. In C++ Compiler, ++s return the reference of the s, so ++++s can be compiled by C++ compilers but not in C Compilers.

 

Sent from Windows Mail

You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/RNWtBfjWXQk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-proposal...@isocpp.org.

[wsdwsd]

{

T temp(s);

++s;

return temp;

}

How can I understand I++?

Sent from Windows Mail

[wsdwsd]

I have some problems to ask you. Can I understand i++ in that order? I know compiler needn't do as that.  I don't know whether C++ std have asked compilers do the same things? I mean whether I can understand them in that order without errors.
And do you think
stack.emplace(stack.top()++);
could be written in my codes, for I couldn't do such a thing in a different way easily?
Sent from my Windows Phone

---

From: Billy O'Neal
Sent: ‎2013/‎12/‎21 14:24
To: std-proposals
Subject: Re: [std-proposals] Some questions about ++ operator

[Bo Persson]

wsdwsd skrev 2013-12-21 13:22:
> I have some problems to ask you. Can I understand i++ in that order? I
> know compiler needn't do as that. I don't know whether C++ std have
> asked compilers do the same things? I mean whether I can understand them
> in that order without errors.
> And do you think
> stack.emplace(stack.top()++);
> could be written in my codes, for I couldn't do such a thing in a
> different way easily?

You could write stack.emplace(stack.top()++); , and it is guaranteed to
work. All parameters are fully evaluated, including their side effects,
before a function is called.


Bo Persson


> ------------------------------------------------------------------------
> From: Billy O'Neal <mailto:billy...@gmail.com>
> Sent: 2013/12/21 14:24
> To: std-proposals <mailto:std-pr...@isocpp.org>

> Subject: Re: [std-proposals] Some questions about ++ operator
>
> 1. ++++s is ill formed; ++ can only be applied to an lvalue. ++s = 10 is
> undefined behavior because the write to s as part of ++ and the write
> assigning s to 10 are unsequenced. For instance, a compiler could add 1
> to s and store the result in a register, then assign 10 to s, then
> assign the register contents of the register to s. (Result: s = s + 1)
> The compiler could also add 1 to s, store the result back to s, and then
> assign 10 to s. (Result: s == 10). (Of course, undefined behavior means
> more than this, but these are the most likely actual behaviors by an
> actual compiler)
> 2. No. That is semantically what occurs, but a compiler is under no
> obligation to actually do the operations in that order. (If it were done
> as separate statements, the compiler would have no freedom to reorder here)
> 3. stack.emplace(stack.top()++); is well defined because the evaluation
> of function arguments is sequenced before the execution of a function.
> Therefore, the ++ must occur before the emplacement (at least as far as
> observable behavior of the program is concerned). See N3691 1.9
> [intro.execution]/15:
>
>
> When calling a function (whether or not the function is inline),
> every value computation and side effect
> associated with any argument expression, or with the postfix
> expression designating the called function, is
> sequenced before execution of every expression or statement in the
> body of the called function.
>
>
>
>

[wsdwsd]

Thank you. And that question,can I understand the meaning of i++ like
int tmp(i);
++i
return tmp;
Without understanding errors?

I don't care how compilers do. I'd like to know if this kind of understand will bring errors to me?
I know most class objects are did as that, can I understand internal objects of that way?

Sent from my Windows Phone

---

From: Bo Persson
Sent: ‎2013/‎12/‎21 21:19
To: std-pr...@isocpp.org
Subject: [std-proposals] Re: Some questions about ++ operator

[Thiago Macieira]

On sábado, 21 de dezembro de 2013 21:37:55, wsdwsd wrote:
> Thank you. And that question,can I understand the meaning of i++ like
> int tmp(i);
> ++i
> return tmp;
> Without understanding errors?
>
> I don't care how compilers do. I'd like to know if this kind of understand
> will bring errors to me? I know most class objects are did as that, can I
> understand internal objects of that way?

I don't know about others, but I'm still struggling to understand what you
want to propose. I understand you're asking questions about what's currently
defined and not, but please tell us what you want to propose to C++. It will be
better for us to advise you if we understand your end-goal.

See also: http://meta.stackoverflow.com/questions/66377/what-is-the-xy-problem

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[wsdwsd]

Thank you. What I want is to make internal types work as same as class types.

As a iterator:

iter++ equals to

auto iter_temp(iter);

++iter;

return iter_temp;

But as a internal-type, what i++ means? Is it:

int i(0);

Does i++ equal to:

auto temp(i);

++i;

return temp;

?

Sent from Windows Mail

[Ville Voutilainen]

On 21 December 2013 19:12, wsdwsd <eulo...@live.com> wrote:
> Thank you. What I want is to make internal types work as same as class
> types.

That's not a standard proposal, since they already can be made to work the
same. Therefore this is completely off-topic.

>
> As a iterator:
> iter++ equals to
> auto iter_temp(iter);
> ++iter;
> return iter_temp;
>
> But as a internal-type, what i++ means? Is it:
>
> int i(0);
> Does i++ equal to:
> auto temp(i);
> ++i;
> return temp;
> ?

I don't know what that int i(0); is doing there, but otherwise the
answer is yes.

[wsdwsd]

int i(0);
==
int i=0;
I'd like to tell you I is a int.

Sent from my Windows Phone

---

From: Ville Voutilainen
Sent: ‎2013/‎12/‎22 1:35
To: std-pr...@isocpp.org
Subject: Re: [std-proposals] Re: Some questions about ++ operator

[Thiago Macieira]

On sábado, 21 de dezembro de 2013 17:12:01, wsdwsd wrote:
> Thank you. What I want is to make internal types work as same as class
> types.

Why? It's been like that for the entire history of C++, and for 40 years if
you count the history of C before it.

Generally, whenever the standard says explicitly that something is undefined
behaviour, it has a good reason to do it. Often having to do with letting the
compiler have freedom to optimise. Undefined behaviours are not bugs. they are
intentional. So you must have a very good reason to change them.

Note also that your problem isn't the operations actually performed, but the
fact that they're unsequenced with relation to other things happening around
the same time. If you're going to require the sequencing, please make sure
that you understand the implications of doing it.

[Johannes Schaub]

Am 21.12.2013 07:24 schrieb "Billy O'Neal" <billy...@gmail.com>:
>
> . ++s = 10 is undefined behavior because the write to s as part of ++ and the write assigning s to 10 are unsequenced.

This is wrong. ++s = 10 is well defined.

[Billy O'Neal]

If so, then why is that?

Billy O'Neal

https://github.com/BillyONeal/

http://stackoverflow.com/users/82320/billy-oneal

Malware Response Instructor - BleepingComputer.com

--

[David Krauss]

Is this discussion on-topic here? This isn't the std-discussion list, but even if it were, this would all be answered much faster on StackOverflow, likely by linking to a preexisting Q&A page.

Simply referring to the C++11 spec, "The result [of prefix ++] is the updated operand; it is an lvalue…", and of compound assignment expressions to which prefix ++ is equivalent, "In all cases, the assignment is sequenced after the value computation of the right and left operands, and before the value computation of the assignment expression."

It doesn't really matter anyway; you shouldn't write ++s=10 or ++++s whether or not it's well-defined. To play devil's advocate, such expressions may be produced by macros, but only the sort of macro that should be replaced by an inline function.

As for the other cases in the original post, they are more than frequently asked on StackOverflow.

On 12/22/13 10:29 AM, Billy O'Neal wrote:

[Billy O'Neal]

Makes sense. Thanks David!

Billy O'Neal

https://github.com/BillyONeal/

http://stackoverflow.com/users/82320/billy-oneal

Malware Response Instructor - BleepingComputer.com