Click here to Skip to main content
15,888,286 members
Articles / Programming Languages / C++

linked_map

Rate me:
Please Sign up or sign in to vote.
3.48/5 (9 votes)
21 Apr 2006CPOL3 min read 47K   839   16   9
A template to traverse STL maps in insertion order.

Introduction

linked_map is a C++ template wrapper of the std::map associative container that:

  • as entries are inserted into the map, they are joined in an ordered double linked list.
  • every time you call get or insert, the map pair's linked list node is removed from its current position and placed at the end.

This is very useful for implementing a “least recently used” discipline for a cache. For example, you may want to keep frequently accessed customers in memory, and discard the less frequently accessed. For example:

class customer
{
};

typedef linked_map <std::string,customer,10> customer_cache;

or even make the linked_map manage the deallocation of memory overwriting some virtual functions:

class customer_ptr_cache: public linked_map <std::string,customer *,10>
{
    public:
    ~customer_ptr_cache()
    {
        clear();
    }
    void delete_value( const iterator & i)
    {
        std::pair <bool,customer*> least_used_customer = at ( i );

        delete least_used_customer.second;
    }
}

Now, you could freely add and get customers from your cache, and be sure that there won't be no more than 10 in memory, and if the cache has to discard a customer, it will be the "least used" one.

Background

linked_map is a very simple template. It has an inner std::map that holds your value, and a pointer to a double linked list node. Something like this:

Image 1

That way, we can re-link the nodes of the linked list to track the insertion/get/erase order, keeping the tree order to look up keys efficiently. Here is an example of the structure before and after the method get() is called for the left child node of the tree (previous nodes hidden for clarity):

Image 2

Image 3

Using the code

The interface of the class is:

template <typename K,typename V,typename Pr = std::less<K>,int Cap = -1 >
class linked_map;

boolean insert(const K & k,const V & v);

Inserts the pair <k,v> and places its corresponding linked node at the end of the list, and returns true. Returns false if that key is already in the linked_map.

void erase(const iterator & iter);

Erases the entry corresponding to the iterator iter.

void erase(const K & k);

Erases the entry with the key k.

void clear();

Clears the map and linked_list elements. Calls delete_value() for each element.

boolean empty();

Returns true if the linked_map has no elements, false otherwise.

std::pair<boolean,V> get(const K & k);

Returns <true,val> if there is a <k,v> entry with key k, and moves its corresponding linked_list node to the end. Or <false,val()> otherwise.

std::pair<boolean,V> at( const iterator & iter)

Returns <true,val> if there is a <k,v> entry for the iterator iter, or <false,val()> otherwise. Doesn't change the linked_list order.

size_t size()

Returns the number of items in the linked_map.

iterator begin()

Returns an iterator to the beginning (least recently used) element of the linked_map.

iterator end()

Returns an iterator just past the last element of a linked_map.

virtual void delete_value(const iterator & i)

This function will be called for every erase operation. You can override it to de-allocate your value with free or delete. Please don't change anything but the value from here!! Don't forget to override the destructor also.

Points of Interest

Although I did my best to test this code, I know this is not a final work. I'm open to any suggestions, corrections, improvements, etc. Also, I would like to say that in my opinion, this kind of containers are very useful, and should be part of the standard. Perhaps, a linked_set and a linked_hash (a hash first, actually), are the next steps.

In the sources, you will find the linked_map.h file, and a VC++ 6.0 test project where I call the insert/get/erase functions randomly, checking memory leaks and the consistency of the data.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer
Argentina Argentina
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
GeneralMy vote of 5 Pin
aputic9-Aug-11 10:59
aputic9-Aug-11 10:59 
GeneralAlternative implementation [modified] Pin
dtrebbien@gmail.com2-Jan-10 13:11
dtrebbien@gmail.com2-Jan-10 13:11 
QuestionWhy not a list? Pin
Pierre Couderc6-Sep-06 2:49
Pierre Couderc6-Sep-06 2:49 
AnswerRe: Why not a list? Pin
Pierre Couderc6-Sep-06 5:20
Pierre Couderc6-Sep-06 5:20 
GeneralBoost Multi-index containers Pin
thog25-Apr-06 16:41
thog25-Apr-06 16:41 
AnswerRe: Boost Multi-index containers Pin
lagos_fernando28-Apr-06 4:45
lagos_fernando28-Apr-06 4:45 
GeneralI got it, ... Pin
WREY29-Sep-05 7:37
WREY29-Sep-05 7:37 
... and not a moment too soon because I can see other uses and expansion of the concept to map containers in combination with other containers and collections.

To see the light, first start off understanding there are two STL containers involved here: a map, and a link list.

The map acts as the tree (because it is stable and from which you can establish your tree configuration), with the link list acting as the "work horse" of the concept you're implementing.

The link list in this instance is handled as double.

Because maps need to have their keys unique, that's how you set up your tree. Then according to how you insert entries into the map, that's how you are describing your tree. Understandably, you NEED to be careful how you input new entries into the map since you'll be affecting the configuration of the tree.

The 'value' part of the map key pair is what goes to the back of the double link list, which means if you have (let's say) 20 entries already in the map, when a new entry is made, that entry gets placed into the map at its proper location (let's say the 8th position), but its entry into the link list will go directly to the last position. This means you'll have position '8' in the map, existing at position '21' in the link list.

Then if you were to make another entry into the map, and this new entry gets placed at position '15' in the map, it will nonetheless end up at position '22' in the link list.

Now, supposed you were to do a "get" for the 3rd entry in the map, doing so will cause that entry to remain at its 3rd position in the map, but will result in its value getting placed at the end position in the link list. IOW, the map remains constant (except when you make a new entry to it), but it's the double link list that constantly gets shuffled around (which is not a bad thing, because it serves other benefits, one being as the MRU data of the tree).

Not only does the link list serve as storage for the map, but because its movements are occurring in a sort of sequential manner, it can serve as index to other containers or as a timestamp for other kind of activities.

Not bad, I believe there is definite use for me of it in the future.

Big Grin | :-D

William

Fortes in fide et opere!

-- modified at 13:41 Thursday 29th September, 2005
GeneralTerribly confusing. Pin
WREY10-Sep-05 11:27
WREY10-Sep-05 11:27 
GeneralRe: Terribly confusing. Pin
packerx13-Sep-05 16:55
packerx13-Sep-05 16:55 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.