Re: Inlining and copy-elision
Ofer Porat ha scritto:
----- Original Message -----
From: "Alberto Ganesh Barbati" <AlbertoBarbati@libero.it>
Newsgroups: comp.std.c++
| But the actual content of the copy constructor is relevant to question
| anyway.
It's difficult to tell whether you really don't understand my question
or
are just pretending not to.
Please don't be rude. I think I have well understood your question,
however you keep seeing the problem in the wrong way and that prevents
you from understanding my answer.
are just pretending not to. The compiler is given the following
complete
and compilable source file
==========
struct T
{
T()
{
}
T (T const&);
};
inline void g(T const& p)
{
T q(p);
}
int main()
{
g(T());
return 0;
}
==========
The compiler is not given any other source file. No link takes place.
The other code
will be written, compiled and linked separately some time in the future.
The compiler
still has to generate an object file from this isolated source file.
When generating
code for *this* compilation, the compiler must decide whether to
generate a call
to the copy constructor or not.
No. It doesn't. That is needed with the legacy compiler/linker approach,
but the standard does *not* mandate such approach. In fact, smarter and
more recent compilers can produce output that is somehow "richer" than
plain old "object code" and this *allows* deferring the decision at a
later time, during link-time code generation, which is a much more
complex step than legacy linking. It doesn't matter if linking occurs
immediately or the next year.
observable behavior. If the copy constructor does alter observable
behavior, the only
rules under which the compiler is permitted to elide the copy is section
[class.copy]
clause 15. The relevant rule for this code is the one that says that a
copy of a
temporary may be elided if the temporary is not bound to a reference,
and as long as
"semantic restrictions are respected". This is where the inlining issue
comes in. The
standard says nothing about what kind of transformations are allowed
during inlining.
It doesn't even say that inlining must not change program behavior (at
least not that I
could find, maybe I missed it.)
Apart from the fact that an "inline function shall be defined in every
translation unit in which it is used" ([dcl.fct.spec] para 4) and a few
other technicalities, the inline specifier shall not alter the behaviour
of the program in any way. The standard need not specify that explicitly
(it would need to be explicit if it were the other way around).
Let me explain why I asked this question in the first place. I was
thinking about
std::vector<T>::push_back(T const&);
Say you write code like this
std::vector<T> v;
v.reserve(10);
v.push_back(T(/* some valid construction of T */));
What usually happens during the 3rd statement is that a temporary T is
created and then
copied (with placement new) into the new position in the vector. I was
wondering whether
the compiler could ever elide this copy (based on the copy elision
rules). Since vector
member functions are usually inlined (maybe at multiple depth, but
compilers can do that),
it boils down to the question I asked.
In presence of side effects the copy can't be omitted. In absence of
those side effects, compilers *have* some latitude. A legacy compiler
will probably not omit it, but you must understand that it's a quality
of implementation issue: the standard does not specify what must be
done, because it's not part of the observable behaviour.
The latest draft contains a version of push_back that's based on move
constructors
std::vector<T>::push_back(T&&);
so this could provide a performance enhancement. It's going to be some
time until
compilers support this, so I was just thinking whether compiler can
optimize push_back
even with the existing version. I couldn't find a compiler that elides
the copy in push_back.
Have you tried a compiler with link-time code generation? Be aware that
you must inspect the final executable to actually detect the presence of
the copy. Inspecting the object code is not enough for those beasts.
Regards,
Ganesh
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]