Re: aggregate return warnings
On 10 Maj, 07:18, jg <jgu...@gmail.com> wrote:
On May 9, 2:14 pm, peter koch <peter.koch.lar...@gmail.com> wrote:
On 9 Maj, 22:15, jg <jgu...@gmail.com> wrote:
On May 9, 10:00 am, faceman28...@yahoo.com wrote:
On May 9, 11:06 am, "m...@ieee.org" <snorkel...@gmail.com> wrote:
Easy enough to disregard, but I'm trying to understand the rationale.
Were aggregate returns not allowed in K&R? Is there some other good
reason for this warning?
Most systems have a "calling standard" that defines how parameters are
exchanged among functions.Traditionally, function return values are
returned in registers.
When a function attempts to return an a aggregate, it is usually
impossible to return the structure through the designated return
registers (most compilers won't try even if the structure is small
enough).
What the compiler generally has to do is create a dummy parameter and
return the value that way.
1. This usually disrupts the "calling standard". Thus, such a function
may become uncallable from a module created by another compiler.
The right term for calling stardard is ABI (application Binary
Interface).
The different compilers can generate compatible code if they follows
the same ABI.
2. While I hate to discuss efficiency in code, passing and returning
aggregates by value is probably the most inefficient avoidable coding
practice.
I think efficiency is the issue here. Usually, a compiler allocates a
space
in caller for returning struct value and passes that address to
callee. This
usually isn't efficient.
Why? What is inefficient about this scheme? In practice the overhead
is one instruction (pushing a pointer), and I doubt it can be done any
better.
Probably more than one instruction. For example:
Given the following code:
struct T {...} t;
t = foo(...);
This is not the normal way to write your code. You would normally
initialise when constructing t.
A compiler will do the following:
struct T tmp;
foo(&tmp,...)
t = tmp; // struct assignment
Not exactly, as your definition of tmp will not involve a constructor
call. The pseudocode shown above will only allocate storage for tmp,
calling the constructor from inside foo.
Also, within foo(...), tmp is assigned right before return from foo,
Normally not if (N)RVO is used (and all compilers I know do use that
trick).
which
may be another struct assignment (calling ctor for C++). If a user
writes foo
as:
foo (T *x...)
Those two struct assignments are no longer needed.
There are not two assignments - there is only one. And in your code
where you pass T as a reference (I assume your pointer was meant to be
a reference), you will have to do the assignment yourself - in the
general case by creating a local instance of type T unless you can
cope with the change in semantics (that might result in case e.g. an
exception is thrown).
/Peter