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: Fix std::pair std::is_copy_assignable behavior


2013/4/20 Bo Persson <bop@gmb.dk>:
> François Dumont skrev 2013-04-19 22:30:
[..]
>>     I check again the Standard and I really can't see any problem with the
>> patch. As far as I understand it having std::is_copy_assignable being true
>> is not a guaranty that the expression will compile but making std::pair
>> is_copy_assignable friendly doesn't violate it neither.
>>
>>     I also see that std::pair is already using std::enable_if to disable
>> some constructors. I check the ChangeLog and it was not associated to a any
>> ISO DR. I don't know why at that moment the same kind of modification hadn't
>> been done for the assignment operators but the patch is not doing more than
>> what has been done at that time.
>
> Sorry for barging in like this, but the C++11 standard has some specific
> requirements for those constructors, like:
>
> "Remarks: If U is not implicitly convertible to first_type or V is not
> implicitly convertible to second_type this constructor shall not participate
> in overload resolution."
>
> One rather obvious way of fulfilling this is to use std::enable_if for those
> constructors.

That is right, but this could only be realized (at least my normal
language means) by constraining templates.

> However, I can't see any similar wording for enabling or disabling
> is_copy_assignable. The standard is rather abstract at this point though.

This wording does not exist, because the move/copy assignment
operators cannot be constrained by normal means, because they cannot
be templates according to the language and because the library cannot
introduce a constrained base class for pair, because that would be
user-observable. The base class technique would be possible for tuple,
though. As far as I remember the only reason why this approach does
not work with pair is, because the type of &std::pair<int, int>::first
would no longer be int std::pair<int, int>::* but int __pairbase<int,
int>::*.

- Daniel


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