hash_map iterator

[Charles Herman]

I have the folowing program:


#include <iostream>
#include <ext/hash_map>

using namespace std;
using namespace __gnu_cxx;

typedef hash_map<char*, long, hash<char*> > char_hash_t;
typedef hash_map<char*, long, hash<char*> >::value_type char_pair_t;

int main()
{
char key[100];
char_hash_t ht;

for (long i = 0; i < 10; ++i)
{
sprintf (key, "%lld", 23*i);
ht.insert( char_pair_t ( key, i ));
}

char_hash_t::iterator p;
for (p = ht.begin(); p != ht.end(); ++p)
cout << "key = " << p->first
<< " val = " << p->second << endl;

return 0;
}

When I run it, it prints the line

key = 207 val = 7

then goes into an infinite loop printing out the line

key = 207 val = 8

until I hit ctrl-c.

Can anyone see a problem with it? It looks perfectly good to me.

-charles

 

[Mike Wahler]

I have the folowing program:


#include <iostream>
#include <ext/hash_map>

using namespace std;
using namespace __gnu_cxx;

typedef hash_map<char*, long, hash<char*> > char_hash_t;
typedef hash_map<char*, long, hash<char*> >::value_type char_pair_t;

int main()
{
char key[100];
char_hash_t ht;

'hash_map' is not part of standard C++, so I can't comment on it, but...

for (long i = 0; i < 10; ++i)
{
sprintf (key, "%lld", 23*i);

The correct specifier for 'long' is %ld, not %lld. Perhaps this
is the trouble.

More below.

ht.insert( char_pair_t ( key, i ));
}

char_hash_t::iterator p;
for (p = ht.begin(); p != ht.end(); ++p)
cout << "key = " << p->first
<< " val = " << p->second << endl;

return 0;
}

When I run it, it prints the line

key = 207 val = 7

then goes into an infinite loop printing out the line

key = 207 val = 8

until I hit ctrl-c.

Can anyone see a problem with it? It looks perfectly good to me.

(it seems to me that from your logic, a 'key'
of 207 should have a 'value' of 9 (207 / 23). I suppose an
invalid printf() format specifier could generate such bogus values,
which might cause your 'for' loop's iteration to 'step over' the
value specified by its conditional expression.

OF course all this is just speculation, since an invalid printf()
format specifier results in 'undefined behavior'.

HTH,

-Mike

 

[Ron Natalie]

char key[100];
char_hash_t ht;

for (long i = 0; i < 10; ++i)

Why are you using long?

{
sprintf (key, "%lld", 23*i);
ht.insert( char_pair_t ( key, i ));
}

You are inserting ten items with the same value "(char*) key".
char* is a pointer value (which never changes over your loop).
It is NOT a string type.

You'd get what you wanted if you had defined the using std::string.

hash_map by the way is NOT part of the C++ standard.

 

[Charles Herman]

I have the folowing program:


#include <iostream>
#include <ext/hash_map>

using namespace std;
using namespace __gnu_cxx;

typedef hash_map<char*, long, hash<char*> > char_hash_t;
typedef hash_map<char*, long, hash<char*> >::value_type
char_pair_t;

int main()
{
char key[100];
char_hash_t ht;

for (long i = 0; i < 10; ++i)
{
sprintf (key, "%lld", 23*i);
ht.insert( char_pair_t ( key, i ));
}

char_hash_t::iterator p;
for (p = ht.begin(); p != ht.end(); ++p)
cout << "key = " << p->first
<< " val = " << p->second << endl;

return 0;
}

When I run it, it prints the line

key = 207 val = 7

then goes into an infinite loop printing out the line

key = 207 val = 8

until I hit ctrl-c.

Can anyone see a problem with it? It looks perfectly good to me.

-charles

Thanks to everyone for answering my post.

It turns out the fact that I used char key[100] was the problem (thanks to
Ron for pointing this out). When I used new to allocate new memory for
each key inside the loop, everything works well. Off course, this raises
the problem of deleting the memory when I am through with the hash map. I
think I will use ostringstream to create the keys. But will this memeory
actually be freed when i am finsished with the hash map?

There were severalissues raised by the repondents. I cannot use std::string
because hash_map is not overloaded to accept string. So I could use string
(which is what I would end up with after using ostringstream) and then use
c_str() to extract the char, or I could use the method I used.

Contrary to your and my intuition, "%lld" is the correct specifier for a
long int, not "%ld" - this is using g++.

I am using long becaue my problem domain demands it.

-charles

 

[=?iso-8859-1?Q?Juli=E1n?= Albo]

Charles Herman escribió:

There were severalissues raised by the repondents. I cannot use std::string
because hash_map is not overloaded to accept string. So I could use string
(which is what I would end up with after using ostringstream) and then use
c_str() to extract the char, or I could use the method I used.

You need only to write an specialization of hash for strings. A simple
way is use the hash for char *, something like:

template <> struct hash <std::string>
{
hash () : hashstr (hash <const char *> () )
{ }
size_t operator () (const std::string & str) const
{
return hashstr (str.c_str () );
}
private:
hash <const char *> hashstr;
};

You may need to modify this depending on your hash_map implementation.

Contrary to your and my intuition, "%lld" is the correct specifier for a
long int, not "%ld" - this is using g++.

l is for long int, ll is for long long int. See man 3 printf

Regards.

 

[Ron Natalie]

There were severalissues raised by the repondents. I cannot use std::string
because hash_map is not overloaded to accept string. So I could use string
(which is what I would end up with after using ostringstream) and then use
c_str() to extract the char, or I could use the method I used.

The hash_map doesn't need to be overloaded. It's the hash function that
the STL only provides the char* overload.

You could always write
template <> class hash<std::string> {
public:
size_T operator(const std::string& h) {
return hash<const char*>(h.c_str());
}
};

Contrary to your and my intuition, "%lld" is the correct specifier for a
long int, not "%ld" - this is using g++.

Contrary to your understanding, %lld IS for "long long int." The fact that
it works for you is purely coincidental.

I am using long becaue my problem domain demands it.

Not as you've expressed it here.