Section: 16.4.4.6 [allocator.requirements] Status: CD1 Submitter: Matt Austern Opened: 2000-08-22 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with CD1 status.
Discussion:
From lib-7752:
I've been assuming (and probably everyone else has been assuming) that allocator instances have a particular property, and I don't think that property can be deduced from anything in Table 32.
I think we have to assume that allocator type conversion is a homomorphism. That is, if x1 and x2 are of type X, where X::value_type is T, and if type Y is X::template rebind<U>::other, then Y(x1) == Y(x2) if and only if x1 == x2.
Further discussion: Howard Hinnant writes, in lib-7757:
I think I can prove that this is not provable by Table 32. And I agree it needs to be true except for the "and only if". If x1 != x2, I see no reason why it can't be true that Y(x1) == Y(x2). Admittedly I can't think of a practical instance where this would happen, or be valuable. But I also don't see a need to add that extra restriction. I think we only need:
if (x1 == x2) then Y(x1) == Y(x2)
If we decide that == on allocators is transitive, then I think I can prove the above. But I don't think == is necessarily transitive on allocators. That is:
Given x1 == x2 and x2 == x3, this does not mean x1 == x3.
Example:
x1 can deallocate pointers from: x1, x2, x3
x2 can deallocate pointers from: x1, x2, x4
x3 can deallocate pointers from: x1, x3
x4 can deallocate pointers from: x2, x4x1 == x2, and x2 == x4, but x1 != x4
[Toronto: LWG members offered multiple opinions. One
opinion is that it should not be required that x1 == x2
implies Y(x1) == Y(x2), and that it should not even be
required that X(x1) == x1. Another opinion is that
the second line from the bottom in table 32 already implies the
desired property. This issue should be considered in light of
other issues related to allocator instances.]
Proposed resolution:
Accept proposed wording from N2436 part 3.
[Lillehammer: Same conclusion as before: this should be considered as part of an allocator redesign, not solved on its own.]
[ Batavia: An allocator redesign is not forthcoming and thus we fixed this one issue. ]
[ Toronto: Reopened at the request of the project editor (Pete) because the proposed wording did not fit within the indicated table. The intent of the resolution remains unchanged. Pablo to work with Pete on improved wording. ]
[ Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which was subsequently split out into a separate paper N2436 for the purposes of voting. The resolution in N2436 addresses this issue. The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. ]