This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix C++ strict-aliasing issues with memcpy folding


On 02/22/2010 12:28 PM, Mark Mitchell wrote:
Jason Merrill wrote:

2) Specify that for some types, initialization is complete when the
initialization of each member is complete.  Perhaps this could just be
for any type with an implicitly defined constructor, or even a
user-defined constructor with an empty body?

"User-defined constructor with an empty body" is a logical generalization of trivial constructor, but not one previously in the standard; if we do this here, I think we should do it everywhere.

It seems to me more like a generalization of aggregate; I was thinking of constructors that do all the initialization via mem-initializers, which are not trivial.


I guess the naive meta-question (and I am naive, so I will ask it), is
why it's desirable that:

    pair<X, Y>   *p = ::operator new(sizeof(pair<X,Y>));
    ::new (&p->first) X(...);
    ::new (&p->second) Y(...);

be a valid way to create a pair<X, Y>?

Pair was up to 14 different constructors to support different uses, and LWG wanted to reduce that.


I gather what we're trying to do is to avoid the cost of a copy, given
we of course cannot design constructors for pair that match the
constructors for X and Y, so that the constructor for pair can itself do
the construction.

Yep.


But, can't the compiler already elide the copy if we do:

pair(X(...), Y(...))

?

If not, it seems to me that it would be nicer to extend the language so
that we *can* do that, possibly by adding syntax if needs be.

A good point; that sort of thing is one reason I wanted to figure out a way to get move semantics out of pass-by-value rather than mess with rvalue references. I guess we can still do copy elision with inlined refs, though not in the absence of inlining...but certainly a forwarding constructor like that could be inline. I'm not sure why that would not be adequate; Paolo, do you have any more background?


I see that N3024 introduces the concept of "fixed-layout class" to implement my #2.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3024.pdf

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]