Title
Requirements for fancy pointers might be insufficient for self-referential implementation of containers
Status
new
Section
[allocator.requirements.general]
Submitter
Jiang An

Created on 2024-04-07.00:00:00 last changed 1 month ago

Messages

Date: 2024-05-01.09:11:42

Proposed resolution:

This wording is relative to N4971.

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

    -2- In subclause [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.

Date: 2024-05-15.00:00:00

[ 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).)"

Date: 2024-04-07.00:00:00

Currently, [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.

History
Date User Action Args
2024-05-01 09:11:42adminsetmessages: + msg14091
2024-04-13 13:02:59adminsetmessages: + msg14055
2024-04-07 00:00:00admincreate