Effective STL-Associative container

Efficient stl-associated containers

The most important thing in a standard associative container is that it is based on equivalence rather than equality. For example, the basic function library has the Find function, but for the set associative container there is also the Find member function. Because the standard associative containers remain orderly, each container must have a comparison function that defines how to keep things in order (by default, less). The equivalence is defined by this comparison function, so users of the standard associative container simply need to specify a comparison function for any container they want to use

The comparison type must be specified for the associated container of the pointer

It is important to be clear that for a container, the iterator inside the container is a pointer to the container object, such as an associative container to the pointer type, and the value of the iterator that uses the container is still a pointer to that object. Like what:

set<string*> SSP;

Ssp.insert (newstring ("ADFA"));

Ssp.insert (newstring ("Bdfa"));

Ssp.insert (newstring ("CDFA"));

Ssp.insert (newstring ("Ddfa"));

Then write a program that wants to print the string;

for (Set<string*>::const_iteratori = Ssp.begin (); I!=ssp.end (); i++)

cout<<*i<<endl;

See is four hexadecimal digits, *i is not a string, it is a pointer to a string. If you modify *i to **i, you may get the correct answer. However, it may not be because the flags ordered in set are sorted by the nature of the elements in set, that is, by the string pointer.

set<string*,less<string*>,allocator<string*>>ssp;

If you want the string* pointer to be a string value to determine that the sort is stored in the set, you cannot use the default comparison functor. It needs to be customized, with its object with a string* pointer and sorted by the string value pointed to. That is, define your own comparison function for the associated container.

Avoid modifying the keys of Set and multiset in situ

All associative containers, sets, and multiset keep their elements in order, and the proper behavior of these containers depends on the order in which they are kept. If you modify the value of an element in the associative container, the new value may not be in the correct position, and it will break the order of the container. Do not modify the part of the key value in set and map, otherwise it will affect the sort of set

If you change the elements in the associative container, you must make sure that the key Values section is not changed, which affects the ordered element part. For non-key value parts, you can modify it at will. If you want to modify the elements in the associative container, the best way is to assign the element to the temporary variable, then delete the element in the container and insert the modified temporary variable into the container.

Using an ordered vector instead of an associative container, you can think of a vector that uses contiguous memory, and for an associative container, there are several pointers, and a page can store more objects than the associated container, and it will not cause and break. There is no overhead when storing objects in a vector, but there are three pointers or two pointers and an int for the associative container. If our data structures are large enough, they can be divided into multiple memory pages, but the vectors need fewer pages than the associated container, because the associative container appends three to each object.

Storing data in an ordered vector is likely to consume less memory than storing the same data in a standard associative container, and finding a binary lookup in an ordered vector may be faster than finding it in a standard associative container when page errors are worth noting. But be sure to understand the premise of using vectors instead of associative containers.

When the word is considered efficient, there is a difference between map::operator[] and Map.insert (), and for a map container, the operation of inserting an element:

map<int,object>m;

M[1] = 1.50;

Expression M[1] is a simplification of m.operator[] (1), so this is a map::operator[] call. That function must return a reference to an object because the mapping type of M is object. Here, there is nothing in M, so the key 1 has no entry in the map. Once operator[] constructs an object by default as the value associated to 1, and then returns a reference to that object. Finally, object becomes the assignment target, and the value assigned is 1.50. The whole process is to construct an object by default, and then we immediately assign it a new value. If constructing an object with the desired value is obviously more efficient than constructing the object by default, then we should replace the use of operator[] with a straightforward insert call.

Typedefmap<int,object> Obj_map;

M.insert (Obj_map::value_type (1,1.50));

The code above takes advantage of value_type, which is important for map and Multimap, and the type of the container element is always some pair.

Therefore, insert is more efficient than operator[when using the Add feature. But when we do the update, the opposite is the case.

M[k] = v; Use operator[] to update the value of K to V

M.insert (Obj_map::value_type (k,v)). First->second= V; Use Insert to update the value of V to V

The insert call requires an argument of type Obj_map::value_type (pair<int,object>), so when we call insert, we have to deconstruct and construct an object of that type. Causes a call to a destructor and constructor, operator[] does not use a pair object, so it does not construct and deconstruct pair and object.

Summary: When adding an element to a map, we conclude that insert is better than operator[], and operator[when updating an element value already in the map.

Effective STL-Associative container