Comment 4 for bug 565116

Ok, I missed that. I assumed it would be similar to boost and std_ext's
hashed maps... in that rehashing only invalidated iterators. I guess if it's
documented it can't be a bug.

My implementation relies heavily on the objects not moving after they were
inserted. Perhaps if I realized this sooner I may have designed differently
but as it is, it is too far along to change now. My initial use of your map
was for a lookup-only use... after the initial set-up of the map I never
modified it again, and thus my reference were stable.

This is my second position I was trying to use your map, and I think I'll
just switch back to boost::unordered_map for this since stability of
references at least are guaranteed and I can get the most performance gain
in my situation by keeping references.

Thanks,
Marius.

On Sat, Apr 17, 2010 at 5:38 AM, Paul Pogonyshev <email address hidden> wrote:

> I added the following text in 'Conceptual Differences' section:
>
> * Rehashing or insertion, which can indirectly cause it, invalidate
> pointers and
> references to elements, not only iterators. This is because under closed
> hashing scheme
> all elements are stored in a single memory block.
>
> --
> insert somehow not working correctly.
> https://bugs.launchpad.net/bugs/565116
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Miscellaneous Container Templates: New
>
> Bug description:
> The following code gives a problem when an item DOES NOT exist in the map
> already:
>
> ConfigStore::mapped_type& ConfigStore::Get(const key_type& key, const
> mapped_type& default_value)
> {
> boost::recursive_mutex::scoped_lock lock(map_mutex);
> ConfigMap::iterator i = _configMap.find(key);
> if(i != _configMap.end())
> {
> return i->second;
> }
> else
> {
> ConfigStore::mapped_type& newVal =
> _configMap.insert(std::make_pair(key, default_value)).first->second;
> newVal.dirtySetter = boost::bind(&ConfigStore::dirty, this,
> _1);
> dirty(true);
> return newVal;
> }
> }
>
> Then externally I call :
>
> ConfigStore::mapped_type& value = store.Get("key", default_val);
>
> What happens is that value is valid after the call, but later becomes
> invalid. This would suggest that what insert returns is somehow not a
> reference to the actual stored internal value, but rather of another or copy
> of the internal value.
>
> I've tried it with:
>
> typedef std::map<key_type, mapped_type> ConfigMap;
> typedef boost::unordered_map<key_type, mapped_type> ConfigMap;
>
> And it works perfectly, just not with:
>
> typedef mct::closed_hash_map<key_type, mapped_type> ConfigMap;
>
> mapped_type is a class (not pointer) and key_type is unimportant.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/libmct/+bug/565116/+subscribe
>