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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Mon, Feb 22, 2010 at 11:28 AM, Mark Mitchell <mark@codesourcery.com> wrote:

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

my understanding is that it is not just a matter of avoiding the cost of copy,
The core of the problem goes back to leaking implementation
details.  The standard library uses pair<X,Y> in several places
where it needed to return a couple of information -- e.g. that insertion
in an associative container succeed and the value of the iterator,
or key-value pair to insert an associative container, etc.
Arguably, C++98 could have defined special types for that; but
it did not.  Rather, it  just reused the existing pair<X,Y>
because its implementation was just convenient.
So it became part of the public interface.  Implementation details
leaked.  Later on, people wanted to do various advanced stuff with
containers and insertions, etc.  They realized that
they would have to modify the class pair<X,Y> to get the new
functionalities in.  So, pair<X,Y> got modified to the point where
it had 14 constructors!  For any reasonable definition of pair<X,Y>,
14 constructors is just too much. (I bet many people did not
anticipate they had at least 14 different ways of constructing a pair).
Furthermore, most of the complication in pair<X,Y> came from
the leaky interface.  So people decided to push the complexity
back to where it belongs.  Except that now, we have this
notion of objects being constructed piecemeal.

-- Gaby