[cfe-dev] [libc++] clang / libc++ fail to compile the code with boost

[Howard Hinnant]

On Jul 2, 2011, at 11:10 AM, Douglas Gregor wrote:

> 
> On Jul 1, 2011, at 7:55 PM, Eli Friedman wrote:
> 
>> On Fri, Jul 1, 2011 at 7:09 PM, ryuuta <ryuuta at gmail.com> wrote:
>>> Hi,
>>> I bet the problem is in boost implementation but
>>> I'm not 100% sure whether the issue is really on boost side or not.
<snip>
>> Testcase without boost:
>> 
>> #include <map>
>> struct A { int& x; explicit A(int); public: bool operator<(const A&
>> other) const {return x < other.x; }};
>> void f(A* x) { std::map<A, int> y, z; z = y; }
>> 
>> This looks like a boost bug to me... as far as I can tell, the Key
>> type of an std::map is required to be assignable if you're assigning
>> one map to another (although the implementation isn't required to
>> actually use that assignment operator).
> 
> 
> C++0x [container.requirements.general] is fairly clear that assigning a container requires the element type to be move assignable. This is a Boost bug.

Strongly agree.  Especially if you s/copy/move. ;-)  And include the reference [associative.reqmts]/p7:

>  The associative containers meet all the requirements of Allocator-aware containers (23.2.1), except that for map and multimap, the requirements placed on value_type in Table 96 apply instead to key_type and mapped_type. [Note: For example, in some cases key_type and mapped_type are required to be CopyAssignable even though the associated value_type, pair<const key_type, mapped_type>, is not CopyAssignable. —endnote]


To be fair to boost, this was at best unspecified in C++03 and no implementation of map took advantage of it (erase/insert was/is a common algorithm for assignment).  libc++ is probably the first std::lib to recycle nodes under associative container assignment.  This can be a huge performance win for copy assignment.

Howard