Pair trivial move constructor

[Christian Rorvik]

Thanks Daniel,

Is a change planned for libstdc++ and associated gcc release?

On Thu, Nov 29, 2012 at 11:49 AM, Daniel Krügler
<daniel.kruegler@gmail.com> wrote:
> 2012/11/29 Christian Rorvik <christian.rorvik@gmail.com>
>>
>> It's my understanding that in GCC 4.7.2 ABI fixes were put in place to
>> ensure compatibility between code compiled with/without -std=c++11.
>>
>> As part of that std::pair's move constructor was made trivial, with
>> its current definition:
>> constexpr pair(pair&&) = default;
>>
>>
>> The implication of this appears to be that all types contained in
>> std::pair must be either movable or trivially copyable, otherwise the
>> compiler will implicitly delete pair's move constructor and then
>> complain about its usage. Example:
>>
>> #include <utility>
>>
>> struct Foo
>> {
>>     Foo();
>>     Foo(const Foo&);
>> };
>>
>> typedef std::pair<Foo, Foo> FooPair;
>>
>> FooPair create();
>>
>> void test()
>> {
>>     const FooPair x = create();
>> }
>>
>>
>> Produces:
>>
>> a.cpp:15:30: error: use of deleted function 'constexpr std::pair<_T1,
>> _T2>::pair(std::pair<_T1, _T2>&&) [with _T1 = Foo; _T2 = Foo;
>> std::pair<_T1, _T2> = std::pair<Foo, Foo>]'
>> In file included from
>>
>> /usr/local/gcc-4.7.2/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/utility:72:0,
>>                  from a.cpp:1:
>>
>> /usr/local/gcc-4.7.2/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:120:17:
>> note: 'constexpr std::pair<_T1, _T2>::pair(std::pair<_T1, _T2>&&)
>> [with _T1 = Foo; _T2 = Foo; std::pair<_T1, _T2> = std::pair<Foo,
>> Foo>]' is implicitly deleted because the default definition would be
>> ill-formed:
>>
>> /usr/local/gcc-4.7.2/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:120:17:
>> error: non-static data member 'std::pair<Foo, Foo>::first' does not
>> have a move constructor or trivial copy constructor
>>
>> /usr/local/gcc-4.7.2/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/bits/stl_pair.h:120:17:
>> error: non-static data member 'std::pair<Foo, Foo>::second' does not
>> have a move constructor or trivial copy constructor
>>
>>
>>
>> I'm not sure how this sits with the standard requirement for
>> std::pair, but it seems a rather onerous requirement on the user of
>> pair, and must have massive impact on existing code. If ABI
>> compatibility requires the move constructor be default generated,
>> would it make sense to constraint its definition based on whether its
>> members are move constructible or trivially copyable?
>
>
> The problem that you are describing here has recently been fixed by
> accepting
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3471.html
>
> Note that before that paper, the standard did not mandate that the defaulted
> members should be constexpr (fortunately not), but implementations (like
> libstdc++)
> took the granted liberty to mark them as such with the described
> side-effects.
>
> The above paper makes now clear that this technique is no longer feasible
> for
> implementations for the here discussed defaulted members.
>
> - Daniel
>