Problem understanding how objects are returned by value

[Divick]

I was reading this section in Bruce Eckel's book which talks about
passing and returning large objects ( Chapter 11: References & the
Copy-Constructor ), where he explains that how to return big objects /
values from functions and the issues involved therein specifically
w.r.t. reentrency.

He explains that because of reentrency, the object to be returned can't
be located down in the stack (down in relative here, which means that
stack is growing downwards) as an interrupt can come along when you are
returning from a function call, which could override the return value.
And also it can't be returned in a global area (for obvious reasons of
overriding the return value in global location on reenterent call or
for recursion) .

Then he concludes that the only safe place to return values in
registers but registers not being large enough for storing values. Thus


"The answer is to push the address of the return value's destination
on the stack as one of the function arguments, and let the function
copy the return information directly into the destination. This not
only solves all the problems, it's more efficient." (Quote from the
book).

So the problem that I see in the above explanation is that even though
the compiler makes extra space for return value in function arguments
and the callee function pushes the address of object to be returned in
this location, but after all the object is located on to the stack
(being a local object which is being returned by value) and thus by the
same logic of reenterant call, this object's value could be overridden
when an interrupt comes along when the object is being returned from
the function.

Thus how does making extra space in the function arguments for a return
address fix this problem of returning objects be value?

I hope I am clear in my explanation.

Thanks,
Divick

 

[Phlip]

So the problem that I see in the above explanation is that even though
the compiler makes extra space for return value in function arguments
and the callee function pushes the address of object to be returned in
this location, but after all the object is located on to the stack
(being a local object which is being returned by value) and thus by the
same logic of reenterant call, this object's value could be overridden
when an interrupt comes along when the object is being returned from
the function.

Thus how does making extra space in the function arguments for a return
address fix this problem of returning objects be value?

That's a bunch of baloney. (It's also platform-specific, so there might be
newsgroups that can detect the grain of truth within the baloney.)

On architectures with interrupts, and without virtual address spaces in
their CPUs, interrupts do indeed borrow your stack, and write "down" on it,
into the same space as your called functions could use.

However, any object returned by value is written into stack space "above"
your called function. A secret pointer to it goes into the function, and it
writes there. (Look up "return value optimization" to cover advanced
versions of this system.)

So you don't need to worry about such things, and you can return objects by
value freely, even on platforms with old-fashioned style interrupts and
hence old-fashioned style threading. Modern CPUs provide virtual contexts
that swap in and out automatically, so your stack is never borrowed. I
think!

 

[peter koch]

Divick wrote:
[snip]
(Bruce Eckel quote

"The answer is to push the address of the return value's destination
on the stack as one of the function arguments, and let the function
copy the return information directly into the destination. This not
only solves all the problems, it's more efficient." (Quote from the
book).
[snip]

Thus how does making extra space in the function arguments for a return
address fix this problem of returning objects be value?

I hope I am clear in my explanation.

I believe you were not! I agree with Philip that most of your post was
difficult to understand. But the Eckel quote above looks as if it is
simply a description of the "return value optimization". Look up this
(and perhaps also "named return value optimization") and feel free to
ask any questions if you still do not understand.

/Peter

 

[Divick]

I believe you were not! I agree with Philip that most of your post was
difficult to understand. But the Eckel quote above looks as if it is
simply a description of the "return value optimization". Look up this
(and perhaps also "named return value optimization") and feel free to
ask any questions if you still do not understand.

Well I have got the answer to my question. Basically the explanation is
very subtle. To understand the question, first try to figure out how
would a function return an object by value keeping reentrency in mind.
Once the question is clear, I can try to explain once again what Bruce
meant (in the quote from his book). He could have made it conspicuous
by just using "caller" and "callee" instead of saying "function".

Thanks anyway,
Divick