Re: Inlining and copy-elision
----- 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. 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. Since the compiler doesn't know
anything about the
copy constructor, it must conservatively assume that eliding the copy
*does* alter
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.)
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.
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.
---
[ 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 ]