This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: std::pair copy and move constructor


2013/3/5 François Dumont <frs.dumont@gmail.com>:
> On 02/16/2013 01:21 PM, Daniel Krügler wrote:
>>
>> 2013/2/16 François Dumont<frs.dumont@gmail.com>:
>>>
>>> On 02/15/2013 10:00 PM, Daniel Krügler wrote:
>>>>
>>>> 2013/2/15 François Dumont<frs.dumont@gmail.com>:
>>>>>
>>>>> Hi
>>>>>
>>>>>       I had a problem with the result of
>>>>> std::is_copy_assignable<std::pair<const int, int>>::type which used to
>>>>> be
>>>>> true_type. So here is a patch to fix that.
>>>>
>>>> This patch would break with the requirements of the library. In
>>>> particular it would prevent that std::pair's of references are
>>>> copy-assignable and that exactly is the purpose for the user-provided
>>>> copy-assignment operators of pair (and tuple).
>>>
>>> I knew there must have been something.
>>>
>>> Is there a test showing this problem ?
>>
>> I would expect that the following code would no longer be accepted:
>>
>> #include <utility>
>>
>> int main() {
>>    int i{};
>>    int j{};
>>    std::pair<int&, int&> pii1(i, j);
>>    const std::pair<int&, int&> pii2(i, j);
>>    pii1 = pii2;
>> }
>>
>> because with a defaulted copy-assignment operator, std::pair<int&,
>> int&> would have a deleted copy-assignment operator.
>
>     I finally wonder if the compiler couldn't help here. If the copy
> assignment is deleted why wouldn't the compiler try to use the template
> assignment operator ? Is there something in the Standard saying that only
> the copy assignment operator can be used ? If so, couldn't the Standard be
> amended to allow this behavior ?

It is correct that the copy operation is selected by overload
resolution. But the selection happens by means of the best match,
which can be the deleted function. If this is the case, the code would
be ill-formed, so it doesn't help you.

>      It sounds like a natural behavior when the copy assignment operator is
> default implemented and when this default implementation can't be generated
> that the compiler consider other challengers. In the case of std::pair<int&,
> int&> it even makes a lot of sens to use the template assignment operator as
> the currently manually written copy assignment operator behaves like a
> simple assignment operator as soon as a reference type is involved.

I agree that this sounds like an interesting rule to consider. Let me
add that the currently proposed resolution of

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1402

would have a similar effect for the move constructor/assignment
operator. I'm not sure whether the extended version of this approach,
reaching further to consider possibly matching function templates,
would get enough sympathy by the core language group.

Let me also add that I implemented my previously expressed suggestion
to realize the effect you want to get by means of a conditionally
selected base class of std::pair. It works, but this would violate
existing Library rules as a border case. I'm going to prepare a
library issue for that (because this violation could be considered to
exist just by chance and only affects a very tiny test case), but that
does not mean at this stage that a greater implementation freedom will
automatically fall out of this.

- Daniel


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