SGI hash: existence of a memory leak impossible to solve?

[rolivawdaneel]

Hello,

I am using SGI's hash_map in such a way that there is an inherent
memory leak. Let me explain:

1- My hash_map takes char* as keys and one of my class, say myClass,
as data. I give the hash_map a comparator for the strings that
compares the contents of the string instead of the address of the
strings (by default hash_map compares the addresses of the strings
(!)).

2- When I want to insert an object of type myClass, I compute its key
using some of the characteristics (fields) of myClass converted into a
zero terminated sequence of chars. Then I insert the (key, object)
into the hash.

3- At a later point, suppose that I want to delete some of the objects
in the hash that satisfy some characteristics . As above, I compute a
key using those characteristics and then I remove the object
corresponding to those characteristics (if any) from the hash using
the hash's erase method. Then I delete the object, and I delete the
string used to lookup the object (the string computed in 3).

The problem is the following: I cannot delete the string computed in 2
to insert the object. If I delete it after insertion (at the end of
2), then the object cannot be looked up any more since the key cannot
be used in a comparison. I cannot delete it in 3 either because there
is no method in hash_map to "retrieve a key", i.e. I cannot retreive
the address of the string used for insertion.

My hash_map is used in a context of "massive" insert/delete so this
innocent-looking memory leak is critical in my case.

I was wondering how other users of the SGI hash_map got around this
issue.

Thank you,
Alex

[John Harrison]

"rolivawdan eel" <ro***********@ hotmail.com> wrote in message
news:c1******** *************** ***@posting.goo gle.com...

Hello,

I am using SGI's hash_map in such a way that there is an inherent
memory leak. Let me explain:

1- My hash_map takes char* as keys and one of my class, say myClass,
as data. I give the hash_map a comparator for the strings that
compares the contents of the string instead of the address of the
strings (by default hash_map compares the addresses of the strings
(!)).

2- When I want to insert an object of type myClass, I compute its key
using some of the characteristics (fields) of myClass converted into a
zero terminated sequence of chars. Then I insert the (key, object)
into the hash.

3- At a later point, suppose that I want to delete some of the objects
in the hash that satisfy some characteristics . As above, I compute a
key using those characteristics and then I remove the object
corresponding to those characteristics (if any) from the hash using
the hash's erase method. Then I delete the object, and I delete the
string used to lookup the object (the string computed in 3).

The problem is the following: I cannot delete the string computed in 2
to insert the object. If I delete it after insertion (at the end of
2), then the object cannot be looked up any more since the key cannot
be used in a comparison. I cannot delete it in 3 either because there
is no method in hash_map to "retrieve a key", i.e. I cannot retreive
the address of the string used for insertion.

My hash_map is used in a context of "massive" insert/delete so this
innocent-looking memory leak is critical in my case.

I was wondering how other users of the SGI hash_map got around this
issue.

Simple, use std::string instead of char* as your key.

BTW your assumption about 'no method to retrieve a key' is incorrect.

hash_map<char*, myClass> map;

char* key = map.find("some_ key")->first;

john

[Kai-Uwe Bux]

rolivawdaneel wrote:

Hello,

I am using SGI's hash_map in such a way that there is an inherent
memory leak. Let me explain:

1- My hash_map takes char* as keys and one of my class, say myClass,
as data. I give the hash_map a comparator for the strings that
compares the contents of the string instead of the address of the
strings (by default hash_map compares the addresses of the strings
(!)).

2- When I want to insert an object of type myClass, I compute its key
using some of the characteristics (fields) of myClass converted into a
zero terminated sequence of chars. Then I insert the (key, object)
into the hash.

3- At a later point, suppose that I want to delete some of the objects
in the hash that satisfy some characteristics . As above, I compute a
key using those characteristics and then I remove the object
corresponding to those characteristics (if any) from the hash using
the hash's erase method. Then I delete the object, and I delete the
string used to lookup the object (the string computed in 3).

The problem is the following: I cannot delete the string computed in 2
to insert the object. If I delete it after insertion (at the end of
2), then the object cannot be looked up any more since the key cannot
be used in a comparison. I cannot delete it in 3 either because there
is no method in hash_map to "retrieve a key", i.e. I cannot retreive
the address of the string used for insertion.

My hash_map is used in a context of "massive" insert/delete so this
innocent-looking memory leak is critical in my case.

I was wondering how other users of the SGI hash_map got around this
issue.

Thank you,
Alex

There are a few ways around this:

(a) [recommended] Use std::string instead of char* as the key. Strings
take care of their memory management automagically.

(b) If you are stuck with char* because some code is beyond your controll,
you could try something along the following lines:

...
Map::iterator iter = the_map.find( some_string );
const char * dummy = iter->first;
the_map.erase( iter );
delete [] dummy;
...

As you can see, iter->first retreives the key for you.
Best

Kai-Uwe