This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 16.4.4.6[allocator.requirements]Status:CD1Submitter: Matt AusternOpened: 2000-08-22Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withCD1 status.
Discussion:
From lib-7752:
I've been assuming (and probably everyone else has been assuming) thatallocator instances have a particular property, and I don't think thatproperty can be deduced from anything in Table 32.
I think we have to assume that allocator type conversion is ahomomorphism. That is, if x1 and x2 are of type X, whereX::value_type is T, and if type Y is X::templaterebind<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. Oneopinion is that it should not be required thatx1 == x2impliesY(x1) == Y(x2), and that it should not even berequired thatX(x1) == x1. Another opinion is that the second line from the bottom in table 32 already implies thedesired property. This issue should be considered in light ofother issues related to allocator instances.]
Proposed resolution:
Accept proposed wording fromN2436 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 proposedwording did not fit within the indicated table. The intent of the resolution remainsunchanged. Pablo to work with Pete on improved wording.]
[Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue whichwas 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 thisissue to Ready status to be voted into the WP at Kona.]