MCT

Comment 7 for bug 565116

Revision history for this message
Lailoken (lailoken-gmail) wrote : Re: [Bug 565116] Re: insert somehow not working correctly.

On Sun, Apr 18, 2010 at 10:35 AM, Paul Pogonyshev <email address hidden>wrote:

> > I guess if it's documented it can't be a bug.
>
> It's simply unavoidable with closed hashing, in the same way as in
> std::vector (as opposed to, say, std::list).

Yes, I agree. Now that I understand closed hashing better I know why as
well.

> > This is my second position I was trying to use your map, and I think
> I'll just switch back to boost::unordered_map
>
> The only active user :(. But I hope you find another use for these maps
> later on ;)
>

I won't be using it in this instance, but I am still using it in the most
critical of our maps... one that is perfect for closed hashing (Where I
store simple pointers as my mapped_type)

> I'll close this bug as invalid.
>
>
> ** Changed in: libmct
> Status: Incomplete => Invalid
>
> --
> 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: Invalid
>
> 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
>