Assuming that the call has access to the declaration, and not the
definition, how can the compiler possibly know whether the compilation
of the function used RVO, and thus whether to pass a hidden argument
to facilitate RVO.
That being the case, is RVO possible in library functions?
Yes.
> Assuming that the call has access to the declaration, and not the
> definition, how can the compiler possibly know whether the compilation
> of the function used RVO, and thus whether to pass a hidden argument
> to facilitate RVO.
In practice it simply has some internal rule about which routines will use a
hidden result pointer argument. At least that's how MSVC and g++ do it.
It's not a big deal.
Either the return value is so small that it fits in registers, in which case
there's no need for RVO, or it doesn't fit in registers, in which case a hidden
argument is usually passed anyway (an alternative could be to pass the result on
the machine stack, but I have never seen or heard about that being done).
> That being the case, is RVO possible in library functions?
Yes.
Cheers & hth.,
- Alf
In practice, returning a class type in general requires a hidden
parameter, or at least uses one in most implementations.
> Assuming that the call has access to the declaration, and not
> the definition, how can the compiler possibly know whether the
> compilation of the function used RVO, and thus whether to pass
> a hidden argument to facilitate RVO.
> That being the case, is RVO possible in library functions?
There's no difference in the calling conventions when RVO is
concerned. (There's also nothing that says that the compiler
can't know about what happens in the library functions.)
--
James Kanze
That's what I missed... that the standard calling convention
specifies to use a hidden argument for all arguments of a certain
size, and that RVO merely uses this. In my head, the hidden argument
only existed when the compiler used RVO.
Thanks James and Alf.