johneddy101@comcast.net ha escrito:

I'm running into a problem while using hashed indices in a container storing shared_ptr's.
The problem is occuring in the hashed_index::erase(key) method in both the 1_33_1
release and the CVS head version. This is what the problem seems to be:

It is possible that the call to erase (or final_erase_) occurring within the do loop
causes destruction of the passed in key object. The key object (k) is then used in a
comparison in the while portion of the loop (y!=x&&eq(k, key(…))). The default predicate uses
== in this comparison but one of the items (the left hand side) will have already been destroyed.

I don't know if it's too late to try to fix this on time for Boost 1.34; in case I find
the time and permission to do it I'll let you know.

I'm afraid that I don't know a good solution to this problem. I see from your commit
logs on this file that there is a problem using something like is done in the ordered_indices
(deleting equal_range items) whereby it increases the complexity. I can see from the
implementation of equal_range on hashed indices that this is a potentially expensive
operation for non-unique collections with many collisions. However, since speed is a
secondary consideration for me, this is the solution I'm using for now.
 

  c.erase(k);

you do the following?

  std::pair<iterator,iterator> p=c.equal_range(k);
  c.erase(p.first,p.second);

This is a viable solution. The potential performance problem you point out
is actually present in both methods. On the other hand, the different problem
I talk about in the commit logs only affects to erase(first,last), not erase(k),
and is exposed here:

http://open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf

An alternative solution is to do the following:

  c.erase(key_type(k));

i.e. doing an external copy of the key before calling erase(k). This is the
solution I'd use if your keys are cheap to copy.

Thanks,

John

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo