hash_map and juce::String

General JUCE discussion
1

I’ve begun using the non-standard STL extension hash_map in order to store some parameters in my program. Specifically, I’m using a hash_map of typehash_map<String, UserValue*>And I’ve specifically implemented hash_compare for the String datatype, by simply converting to (const char*) and using the built-in hash function. My problem is that I get errors when trying to insert into the map; specifically, I get invalid memory being read when attempting to set a value.[code] glfx.exe!std::_Iterator_base::_Adopt(const std::_Container_base_secure * _Parent=0xcdcdcdcd) Line 170 + 0x9 bytes C++
glfx.exe!std::_Iterator_base::operator=(const std::_Iterator_base & _Right={…}) Line 154 C++
glfx.exe!std::_Iterator_base::_Iterator_base(const std::_Iterator_base & _Right={…}) Line 145 C++
glfx.exe!std::_Iterator_with_base<std::bidirectional_iterator_tag,std::pair<juce::String const ,UserValue *>,int,std::pair<juce::String const ,UserValue *> const *,std::pair<juce::String const ,UserValue *> const &,std::_Iterator_base>::_Iterator_with_base<std::bidirectional_iterator_tag,std::pair<juce::String const ,UserValue *>,int,std::pair<juce::String const ,UserValue *> const *,std::pair<juce::String const ,UserValue *> const &,std::_Iterator_base>(const std::_Iterator_with_base<std::bidirectional_iterator_tag,std::pair<juce::String const ,UserValue *>,int,std::pair<juce::String const ,UserValue *> const *,std::pair<juce::String const ,UserValue *> const &,std::_Iterator_base> & __that={…}) + 0x2f bytes C++
glfx.exe!std::_Bidit<std::pair<juce::String const ,UserValue *>,int,std::pair<juce::String const ,UserValue *> const *,std::pair<juce::String const ,UserValue *> const &>::_Bidit<std::pair<juce::String const ,UserValue *>,int,std::pair<juce::String const ,UserValue *> const *,std::pair<juce::String const ,UserValue *> const &>(const std::_Bidit<std::pair<juce::String const ,UserValue *>,int,std::pair<juce::String const ,UserValue *> const *,std::pair<juce::String const ,UserValue *> const &> & __that={…}) + 0x2f bytes C++
glfx.exe!std::list<std::pair<juce::String const ,UserValue *>,std::allocator<std::pair<juce::String const ,UserValue *> > >::_Const_iterator<1>::_Const_iterator<1>(const std::list<std::pair<juce::String const ,UserValue *>,std::allocator<std::pair<juce::String const ,UserValue *> > >::_Const_iterator<1> & __that=({empty={…} text=??? emptyString={…} },…)) + 0x2f bytes C++

glfx.exe!std::list<std::pair<juce::String const ,UserValue *>,std::allocator<std::pair<juce::String const ,UserValue *> > >::_Iterator<1>::_Iterator<1>(const std::list<std::pair<juce::String const ,UserValue *>,std::allocator<std::pair<juce::String const ,UserValue *> > >::_Iterator<1> & __that=({empty={…} text=??? emptyString={…} },…)) + 0x2f bytes C++
glfx.exe!stdext::_Hash<stdext::_Hmap_traits<juce::String,UserValue *,stdext::hash_compare<juce::String,std::lessjuce::String >,std::allocator<std::pair<juce::String const ,UserValue *> >,0> >::_Get_iter_from_vec(const std::list<std::pair<juce::String const ,UserValue *>,std::allocator<std::pair<juce::String const ,UserValue *> > >::_Iterator<1> & _Iter=({empty={…} text=??? emptyString={…} },…)) Line 279 + 0xc bytes C++
glfx.exe!stdext::_Hash<stdext::_Hmap_traits<juce::String,UserValue *,stdext::hash_compare<juce::String,std::lessjuce::String >,std::allocator<std::pair<juce::String const ,UserValue *> >,0> >::lower_bound(const juce::String & _Keyval={…}) Line 599 + 0x1f bytes C++
glfx.exe!stdext::hash_map<juce::String,UserValue *,stdext::hash_compare<juce::String,std::lessjuce::String >,std::allocator<std::pair<juce::String const ,UserValue > > >::operator[](const juce::String & _Keyval={…}) Line 158 + 0x10 bytes C++[/code]By the way, UserValue is my own class. It doesn’t do anything special in the way of construction or construction, so I’m looking at String. Is there any reason why it might not be able to be held by a hash_map? I’m using VS2008.

2

Never mind. I’m getting errors elsewhere that are the same with a different kind of map.

3

If you’re casting a string to a char*, then the pointer that’s returned will probably become invalid if you change that string in the future, so could that be the problem?

4

The hash_map computes a hash (size_t) based on the input, so it doesn’t store a reference to the value it has hashed. For now, the problem has disappeared, but I’ll re-post when it comes back later.