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
>
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 unordered_ map for this since stability of
just switch back to boost::
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: /bugs.launchpad .net/bugs/ 565116 :mapped_ type& ConfigStore: :Get(const key_type& key, const recursive_ mutex:: scoped_ lock lock(map_mutex); find(key) ; :mapped_ type& newVal = insert( std::make_ pair(key, default_ value)) .first- >second; bind(&ConfigSto re::dirty, this, :mapped_ type& value = store.Get("key", default_val); unordered_ map<key_ type, mapped_type> ConfigMap; hash_map< key_type, mapped_type> ConfigMap; /bugs.launchpad .net/libmct/ +bug/565116/ +subscribe
>
> * 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:/
> 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& default_value)
> {
> boost::
> ConfigMap::iterator i = _configMap.
> if(i != _configMap.end())
> {
> return i->second;
> }
> else
> {
> ConfigStore:
> _configMap.
> newVal.dirtySetter = boost::
> _1);
> dirty(true);
> return newVal;
> }
> }
>
> Then externally I call :
>
> ConfigStore:
>
> 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::
>
> And it works perfectly, just not with:
>
> typedef mct::closed_
>
> mapped_type is a class (not pointer) and key_type is unimportant.
>
> To unsubscribe from this bug, go to:
> https:/
>