That syntax of:
std::map<int, int> m; m.insert(std::make_pair(1, 42)); seems a bit crazy.
Why is there no alternative insert(K k, V v) method which would provide a much saner:
std::map<int, int> m; m.insert(1, 42); Yes, I'm aware of m[1] = 42, but it has its own problems (creating an extra copy of the value object).
I can't tell you why that construct isn't allowed. Perhaps to keep insert similar to other containers' insert method. However, since c++11, there is map::emplace that does what you want.
std::map<int, int> m; m.emplace(1, 42); m.insert(x, y); forces a copy of the two parameters; whereas m.insert(std::make_pair(1, 42)); allows the call to get a const& pair which avoids all copying. That way, map can contain uncopyable objects (or heavy-duty copy objects)
std::make_pair does not lead to copying?
make_pair approach encourages creation of incorrectly-typed pair object, which cannot be passed to insert directly and requires an extra conversion, i.e. an extra copy. Your example actually illustartes that popular mistake very well. Your make_pair will create an <int, int> pair, while insert requires a <const int, int> pair. The compiler will not complain because the former is implicitly convertible to the latter. But the conversion will create a temporary copy. So hello, unnecessary copying!
std::pair<int, int> instead of std::pair<const int, int>.
m.emplace(1, 42)?mapalready worked like this in the original STL before it was incorporated into the standard library, and since the container's value type is a pair, using a pair as the parameter type is simply the most logical way. AFAIK,operator[]was an afterthought, designed as a (inconsistent) convenience function exactly to provide the "saner" alternative you are asking for.