Standard 23.1 - std::map::value_type must be assignable?

[massysett]

I'm puzzled about part of the standard. 23.1 states that items stored
in a container must be assignable. Therefore, the items in a map--that
is, std::pair<const Key, valuemust be assignable. However, such a
pair--with the const Key--is not assignable.

My concern is more than academic; take for instance the following code
to make a copy of a map while eliminating some of the elements:

#include <map>
#include <algorithm>

typedef std::map<char, intMapType;

bool predicate(const MapType::value_type& x)
{
return x.second 1;
}

int main()
{
MapType bigMap;
bigMap['a'] = 1;
bigMap['b'] = 2;

MapType littleMap;

// This shouldn't work, right? Standard 23.1 says objects in
// container must be assignable, but MapType::value_type is
// std::pair<const char, intwhich is NOT assignable
std::remove_copy_if(bigMap.begin(),
bigMap.end(),
std::inserter(littleMap, littleMap.end()),
&predicate);
return 0;
}

This compiles fine on g++ 4.1.2, but I want to make sure I'm not
writing nonstandard code. That leaves me with two questions:

1) is there part of the standard that I'm missing that describes how
maps can have values of std::pair<const Key, valueeven though that
pair is not assignable?

2) is the sample code above standard compliant, and if not, how should
I accomplish something like this?

Thanks,
Omari

[Jim Langston]

massysett wrote:

I'm puzzled about part of the standard. 23.1 states that items stored
in a container must be assignable. Therefore, the items in a map--that
is, std::pair<const Key, valuemust be assignable. However, such a
pair--with the const Key--is not assignable.

My concern is more than academic; take for instance the following code
to make a copy of a map while eliminating some of the elements:

#include <map>
#include <algorithm>

typedef std::map<char, intMapType;

bool predicate(const MapType::value_type& x)
{
return x.second 1;
}

int main()
{
MapType bigMap;
bigMap['a'] = 1;
bigMap['b'] = 2;

MapType littleMap;

// This shouldn't work, right? Standard 23.1 says objects in
// container must be assignable, but MapType::value_type is
// std::pair<const char, intwhich is NOT assignable
std::remove_copy_if(bigMap.begin(),
bigMap.end(),
std::inserter(littleMap, littleMap.end()),
&predicate);
return 0;
}

This compiles fine on g++ 4.1.2, but I want to make sure I'm not
writing nonstandard code. That leaves me with two questions:

1) is there part of the standard that I'm missing that describes how
maps can have values of std::pair<const Key, valueeven though that
pair is not assignable?

2) is the sample code above standard compliant, and if not, how should
I accomplish something like this?

Consider assignable as x = y. The thing is that the key and the value must
be assignable, you need an assignment operator, either default or custom.
The reason being that values are loaded into the map using assignment. A
char is assignable ( ignore the constaness for now ) and so is an int.

The map itself does not have to treat the key as const internally, the
interface does. It is extremely easy to convert a non-const something to a
const something, just not as easy the other way around.

Notice the standard says objects in the container. That is refering to the
key and the value, not the std::pair.

--
Jim Langston
ta*******@rocketmail.com

[jkherciueh]

massysett wrote:

I'm puzzled about part of the standard. 23.1 states that items stored
in a container must be assignable. Therefore, the items in a map--that
is, std::pair<const Key, valuemust be assignable. However, such a
pair--with the const Key--is not assignable.

That observation is an important part of defect report 276:

http://www.open-std.org/jtc1/sc22/wg...fects.html#276

The report remarks:

"It should be noted that there exists a valid and non-contradictory
interpretation of the current text. The wording in 23.1/3 avoids
mentioning value_type, referring instead to "objects stored in a
container." One might argue that map does not store objects of type
map::value_type, but of map::mapped_type instead, and that the Assignable
requirement applies to map::mapped_type, not map::value_type.
Best

Kai-Uwe Bux

[massysett]

On Dec 31, 2:41 am, [e-mail] wrote:

That observation is an important part of defect report 276:

http://www.open-std.org/jtc1/sc22/wg...fects.html#276

The report remarks:

"It should be noted that there exists a valid and non-contradictory
interpretation of the current text. The wording in 23.1/3 avoids
mentioning value_type, referring instead to "objects stored in a
container." One might argue that map does not store objects of type
map::value_type, but of map::mapped_type instead, and that the Assignable
requirement applies to map::mapped_type, not map::value_type.

I thought of that too, but the argument falls apart. 23.1/5: "X
denotes a container class containing objects of type T." Table 65 says
X::value_type returns T. 23.3.1: "typedef pair <const Key, T>
value_type". pair <const Key, Tis not assignable.

At best the standard is confusing on this point; at worst it is simply
inconsistent.