4065. Requirements for fancy pointers might be insufficient for self-referential implementation of containers

Section: 16.4.4.6.1 [allocator.requirements.general] Status: New Submitter: Jiang An Opened: 2024-04-07 Last modified: 2024-05-01

Priority: 3

View other active issues in [allocator.requirements.general].

View all other issues in [allocator.requirements.general].

View all issues with New status.

Discussion:

Currently, 16.4.4.6.1 [allocator.requirements.general]/2.12 imposes a precondition for pointer_traits::pointer_to that r denotes an object whose storage is allocated by the allocator.

However, as mentioned in P0773R0, some containers are self-referential in current implementations, and thus a fancy pointer stored in the last node (as required by LWG 2261) needs to be able to point to a sentinel node in the container object. Given the container object can be constructed at any location, perhaps we should specify that pointer_traits::pointer_to works on any lvalue.

[2024-05-01; Reflector poll]

Set priority to 3 after reflector poll.

"This applies to small-object optimizations too."

"An alternative way to support P0773's "near pointers" would be to require that a sentinel-node container using a "near allocator" must itself be constructed in the near segment. (This is P0773 (B) (2).)"

Proposed resolution:

This wording is relative to N4971.

1. Modify 16.4.4.6.1 [allocator.requirements.general] as indicated:

   -2- In subclause 16.4.4.6 [allocator.requirements],

   1. […]

   2. (2.10) — p denotes a value of type XX::pointer obtained by calling a1.allocate, where a1 == a,

   3. (2.11) — […],

   4. (2.12) — r denotes an lvalue of type T& obtained by the expression *p,

   5. […]

   […]

   pointer_traits<XX::pointer>::pointer_to(r)
   

   -33- Result: XX::pointer

   -34- Postconditions: Same as pLet p1 denote the return value. *p1 refers to the same object as r.