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


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.

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>?

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.

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.

And, if not that, then I guess my suggestion for doing what you
originally suggest would be that classes willing to be constructed in
this fashion (and I think that classes should have to sign off
explicitly, since otherwise it doesn't seem to me that they can be sure
of internal consistency), have a constructor that takes a std::nop
parameter, and that this is black magic which causes the compiler not to
run constructors for subobjects; it's always a no-op.  So, that after
the code above, you'd write:

  new (p) pair<X, Y>(std::nop());

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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