Re: [Boost-users] Problem with multi_index and shared_ptr

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2006-12-20 04:18:23

Hello John,

johneddy101_at_[hidden] 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.

Umm... Thank you for spotting this, indeed the key passed to erase() can
become
invalid during the process if it physically belongs to one of the
elements to be
erased. Matter of fact, the problem is not specifically related to
shared_ptr's.

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.
>

Do you mean that instead of

  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

Thank you for reporting, good luck with your project.

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