Prefferred method of inserting in map

Suppose I have map

Code:

---

map<string, int> Employees;

---

Which of the following method are best to use for insertion?

1. Assignment using array index notation

Code:

---

Employees["Mike C."] = 5234;
 Employees["Charlie M."] = 3374;

---

2. Assignment using member function insert() and STL pair

Code:

---

Employees.insert(std::pair<string,int>("David D.",1923));

---

3. Assignment using member function insert() and "value_type()"

Code:

---

Employees.insert(map<string,int>::value_type("John A.",7582));

---

4. Assignment using member function insert() and "make_pair()"

Code:

---

Employees.insert(std::make_pair("Peter Q.",5328));

---

#1 does something different than the others. It will replace any existing entries for that key; the rest will not. It's also slightly less efficient if the key didn't previously exist since it has to default-construct a value and then overwrite it.

For most cases in which #1 is not appropriate, I prefer #4. The exception is when make_pair() is not able to automatically determine the appropriate type. The above may actually be such a case; there's no way make_pair() would be able to tell that it should make the first type a string rather than a char*. In such a situation, I would go with #2.

Quote:

---

Originally Posted by Lindley

#1 does something different than the others. It will replace any existing entries for that key; the rest will not.

---

std::map associate key with only one value. So, why would others not replace?

Quote:

---

Originally Posted by Lindley

It's also slightly less efficient if the key didn't previously exist since it has to default-construct a value and then overwrite it.

---

I am not sure but I think others will also be first constructed then they will be put in map. So, why inefficient?

Quote:

---

Originally Posted by Lindley

For most cases in which #1 is not appropriate, I prefer #4. The exception is when make_pair() is not able to automatically determine the appropriate type. The above may actually be such a case; there's no way make_pair() would be able to tell that it should make the first type a string rather than a char*. In such a situation, I would go with #2.

---

Sounds perfect.

numbers 2,3 and 4 are exactly the same thing.

value_type is just a typedef to pair<string, int>

make_pair is just a way to create a pair, with implicit type.

As lindley said 1 and 2 don't do the same thing, so it's up to you.

...

...

The most efficient method is insert when the key is not there, and update when it is: http://stackoverflow.com/questions/9...or-stdmap-find

However, it is a bit convoluted.

Quote:

---

Originally Posted by sunnypalsingh

std::map associate key with only one value. So, why would others not replace?

---

'insert()' will actually fail if the given key already exists within the map.

Quote:

---

Originally Posted by sunnypalsingh

I am not sure but I think others will also be first constructed then they will be put in map. So, why inefficient?

---

The inefficiency happens whenever the key is not yet in the map. If it is in the map, '[]' simply returns a reference to the associated value and assigns the new value. However, in the case it is not, it cannot return a reference. Thus, it will create an object using the default constructor and return a reference to the object accordingly. The value then gets assigned.

'insert()' saves the first step....and constructs the object with the given value in one step thus saving the cost of creating a temporary object.

Quote:

---

Originally Posted by Andreas Masur

However, in the case it is not, it cannot return a reference. Thus, it will create a temporary object using the default constructor and return a reference to this temporary object. The then value gets assigned.

---

I agree except the part where a temporary object is created. The object is nothing temporary.

Quote:

---

Originally Posted by monarch_dodra

I agree except the part where a temporary object is created. The object is nothing temporary.

---

Yep...that is correct...thanks for correcting me.