C++ side effects
in [C++]
|
From: baibaichen on 7 Apr 2008 23:19 hi All the following comes from c++ standards: "Accessing an object designated by a volatile lvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment." According to this definition, consider this function, T ReturnT(){ T result_; //do something return result_; // #1 } At #1, I think 1) if T is scalre type such as int or char, the returning sentence would not have side effects 2) if T is a class type, does returning type T have side effects? and Why? Thanks Chang -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 8 Apr 2008 04:36 baibaichen wrote: > hi All > > the following comes from c++ standards: > > "Accessing an object designated by a volatile lvalue (3.10), > modifying an object, calling a library I/O > function, or calling a function that does any of those operations > are all side effects, which are changes in the > state of the execution environment." > > According to this definition, consider this function, > > T ReturnT(){ > T result_; > //do something > return result_; // #1 > } > > At #1, I think > 1) if T is scalre type such as int or char, the returning sentence > would not have side effects > 2) if T is a class type, does returning type T have side effects? > and Why? > Only if constructing or copying T has any side effects. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 8 Apr 2008 07:53 On 8 Apr., 21:36, "Bo Persson" <b...(a)gmb.dk> wrote: > baibaichen wrote: > > hi All > > > the following comes from c++ standards: > > > "Accessing an object designated by a volatile lvalue (3.10), > > modifying an object, calling a library I/O > > function, or calling a function that does any of those operations > > are all side effects, which are changes in the > > state of the execution environment." > > > According to this definition, consider this function, > > > T ReturnT(){ > > T result_; > > //do something > > return result_; // #1 > > } > > > At #1, I think > > 1) if T is scalre type such as int or char, the returning sentence > > would not have side effects > > 2) if T is a class type, does returning type T have side effects? > > and Why? > > Only if constructing or copying T has any side effects. > > Bo Persson Hmmh, I would have expected you meant either of construction and destruction?! IMO, the compiler is not required to perform a copy construction, even if that has side-effects, [class.copy]/15: "When certain criteria are met, an implementation is allowed to omit the copy construction of a class object, even if the copy constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization.111) This elision of copy operations is permitted in the following circumstances (which may be combined to eliminate multiple copies): -- in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object with the same cv-unqualified type as the function return type, the copy operation can be omitted by constructing the automatic object directly into the function's return value[..]" { Sorry for the long quote, but I thought that it might be of interest for the OP. } And I also think that the requirement only holds strictly if the result is assigned to "an object of static storage duration" ([basic.stc.static]/2), because we cannot decide - given this snippet - whether the compiler sees a way to remove the call of ReturnT() in total or not. But if we assume for a moment that the corresponding function call itself will not be eliminated, we have [basic.stc.auto]/3 again, which is probably, what you had in your mind? Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Bo Persson on 9 Apr 2008 04:20 Daniel Kr�gler wrote: > On 8 Apr., 21:36, "Bo Persson" <b...(a)gmb.dk> wrote: >> baibaichen wrote: >>> hi All >> >>> the following comes from c++ standards: >> >>> "Accessing an object designated by a volatile lvalue (3.10), >>> modifying an object, calling a library I/O >>> function, or calling a function that does any of those operations >>> are all side effects, which are changes in the >>> state of the execution environment." >> >>> According to this definition, consider this function, >> >>> T ReturnT(){ >>> T result_; >>> //do something >>> return result_; // #1 >>> } >> >>> At #1, I think >>> 1) if T is scalre type such as int or char, the returning sentence >>> would not have side effects >>> 2) if T is a class type, does returning type T have side effects? >>> and Why? >> >> Only if constructing or copying T has any side effects. >> >> Bo Persson > > Hmmh, I would have expected you meant either of construction and > destruction?! IMO, the compiler is not required to perform a copy > construction, even if that has side-effects, [class.copy]/15: No, I meant exactly what I wrote. Didn't want to bother the OP with the special case where the copying might be optimized away. :-) The code snippet doesn't say happens to the return value after the call to the function. Missed out on the destruction, though. > > > And I also think that the requirement only holds strictly if the > result is assigned to "an object of static storage duration" > ([basic.stc.static]/2), because we cannot decide - given this > snippet - whether the compiler sees a way to remove the call of > ReturnT() in total or not. But if we assume for a moment that the > corresponding function call itself will not be eliminated, we have > [basic.stc.auto]/3 again, which is probably, what you had in your > mind? > Yes. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 9 Apr 2008 04:43 On 9 Apr., 00:53, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> wrote: > And I also think that the requirement only holds strictly if the > result is assigned to "an object of static storage duration" > ([basic.stc.static]/2), because Please strike this part of my posting, it is not relevant for the discussion and only helps to confuse the reader. Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
|
Pages: 1 Prev: Creating own Virtual method table Next: Demangling typeid. |