Inlined Function still a function call w.r.t. Sequence points?

[joe]

Consider the following program:

include <iostream>

class Bar
{ public:
int getData9() { m_data = 9; return m_data;}
int getData11() { m_data = 11; return m_data;}

int m_data;
};

int main()
{
Bar f;
int a = f.getData11() – f.getData9();

std::cout<<"Answer: "<<a<<std::endl;
}

This program on this (not so great in general) compiler produces an
answer of "0".

My assumption is that each of the function calls should be a sequence
point, and the behavior according to the standard is well defined.
The fact that these function calls happen to be inlined by the
compiler (something a caller has no control over) does not change the
fact that they are indeed "function calls" with regards to what is and
what is not a sequence point.

Any thoughts? References?

Thanks

 

[peter koch]

Consider the following program:

include <iostream>

class Bar
{ public:
  int getData9()   {  m_data = 9;  return m_data;}
  int getData11() {  m_data = 11; return m_data;}

  int m_data;

};

int main()
{
  Bar f;
  int a  = f.getData11() – f.getData9();

  std::cout<<"Answer: "<<a<<std::endl;

}

This program on this (not so great in general) compiler produces an
answer of "0".

My assumption is that each of the function calls should be a sequence
point, and the behavior according to the standard is well defined.
The fact that these function calls happen to be inlined by the
compiler (something a caller has no control over) does not change the
fact that they are indeed "function calls" with regards to what is and
what is not a sequence point.

Any thoughts?  References?

Thanks

Your compiler is wrong. There is a sequence point after each function
call:

[program.execution]
"When calling a function (whether or not the function is inline),
there is a sequence point after the evaluation of all function
arguments (if any) which takes place before execution of any
expressions or statements in the function body."

/Peter

 

[robertwessel2]

Consider the following program:

include <iostream>

class Bar
{ public:
  int getData9()   {  m_data = 9;  return m_data;}
  int getData11() {  m_data = 11; return m_data;}

  int m_data;

};

int main()
{
  Bar f;
  int a  = f.getData11() – f.getData9();

  std::cout<<"Answer: "<<a<<std::endl;

}

This program on this (not so great in general) compiler produces an
answer of "0".

My assumption is that each of the function calls should be a sequence
point, and the behavior according to the standard is well defined.
The fact that these function calls happen to be inlined by the
compiler (something a caller has no control over) does not change the
fact that they are indeed "function calls" with regards to what is and
what is not a sequence point.

Several issues:

- The result should be 2, not 0.

- The function being inlined has no impact on sequence points

- As written, there's nothing that would be impacted by sequence
points anyway.

 

[Triple-DES]

[snip]

  int a  = f.getData11() – f.getData9(); [snip]
My assumption is that each of the function calls should be a sequence
point, and the behavior according to the standard is well defined.
The fact that these function calls happen to be inlined by the
compiler (something a caller has no control over) does not change the
fact that they are indeed "function calls" with regards to what is and
what is not a sequence point.

Any thoughts?  References?

Your compiler is wrong. There is a sequence point after each function
call:

[program.execution]
"When calling a function (whether or not the function is inline),
there is a sequence point after the evaluation of all function
arguments (if any) which takes place before execution of any
expressions or statements in the function body."

This merely tells you that the arguments of a function are fully
evaluated before the execution of the function. The two function calls
f.getData11() and f.getData9() could still be evaluated in any order.

DP
captcha: const

 

[Thomas J. Gritzan]

On 22 Maj, 23:21, joe <[email protected]> wrote:

[snip]

Member functions of interest:

> int getData9() { m_data = 9; return m_data;}
> int getData11() { m_data = 11; return m_data;}

int a = f.getData11() – f.getData9(); [snip]
My assumption is that each of the function calls should be a sequence
point, and the behavior according to the standard is well defined.
The fact that these function calls happen to be inlined by the
compiler (something a caller has no control over) does not change the
fact that they are indeed "function calls" with regards to what is and
what is not a sequence point.
Any thoughts? References?

Your compiler is wrong. There is a sequence point after each function
call:

[program.execution]
"When calling a function (whether or not the function is inline),
there is a sequence point after the evaluation of all function
arguments (if any) which takes place before execution of any
expressions or statements in the function body."

This merely tells you that the arguments of a function are fully
evaluated before the execution of the function. The two function calls
f.getData11() and f.getData9() could still be evaluated in any order.

Yes, but
{ m_data = 9; return m_data;} returns 9 and
{ m_data = 11; return m_data;} returns 11,
order doesn't matter, so 'a' should equal 11-9.

 

[James Kanze]

[snip]

int a = f.getData11() - f.getData9(); [snip]
My assumption is that each of the function calls should be a sequence
point, and the behavior according to the standard is well defined.
The fact that these function calls happen to be inlined by the
compiler (something a caller has no control over) does not change the
fact that they are indeed "function calls" with regards to what is and
what is not a sequence point.
Any thoughts? References?

Your compiler is wrong. There is a sequence point after each function
call:
[program.execution]
"When calling a function (whether or not the function is inline),
there is a sequence point after the evaluation of all function
arguments (if any) which takes place before execution of any
expressions or statements in the function body."

This merely tells you that the arguments of a function are
fully evaluated before the execution of the function.

There's also one before returning from the function. And the
compiler is not allowed to interleave different functions; once
a function is called, nothing outside that function can take
place until the function returns.

The two function calls f.getData11() and f.getData9() could
still be evaluated in any order.

True, but that doesn't matter here.

 

[Triple-DES]

True, but that doesn't matter here.

Yes, as Thomas J. Gritzan also pointed out, this is not relevant here.
I thought the OP was expecting the two function calls to be executed
in a particular order. Obviously this was not the case.

DP

 

[joe]

Thanks for all the responses. That's what I believed.

The assembler output produced is ... amusing

bl _main
li r12, 9 // Load value "9" into register 12
li r12, 11 // Load value "11" into register 12 ??
subf r12, r12, r12 // Subtract r12 by r12 and store in r12


-
Joe