Title
Requirements on internal pointer representations in containers
Status
open
Section
[container.requirements.general]
Submitter
Mike Spertus

Created on 2010-10-16.00:00:00 last changed 63 months ago

Messages

Date: 2019-01-20.16:20:00

Proposed resolution:

Add to the end of [container.requirements.general] p. 8:

[..] In all container types defined in this Clause, the member get_allocator() returns a copy of the allocator used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement. The container may not store internal objects whose types are of the form T * or T & except insofar as they are part of the item type or members.

Date: 2019-01-20.00:00:00

[ 2019-01-20 Reflector prioritization ]

Set Priority to 3

Date: 2018-06-22.06:38:21

[ LEWG Kona 2017 ]

Status to Open: Acknowledged, need wording: (N4618 numbering) 23.2.1 container.requirements.general p8 first sentence. Replace non-normative note with requirement.

See discussion on LEWG Wiki

Date: 2011-08-18.17:55:31

[ 2011 Batavia ]

This may be an issue, but it is not clear. We want to gain a few years experience with the C++11 allocator model to see if this is already implied by the existing specification.

Date: 2011-03-23.00:00:00

[ 2011-03-23 Madrid meeting ]

Deferred

Date: 2010-10-26.20:16:35

[ Pre-batavia ]

This issue is being opened as part of the response to NB comments US-104/141. See paper N3171 in the pre-Batavia mailing.

Date: 2010-11-03.21:20:39

Addresses US-104, US-141

The standard doesn't say that containers should use abstract pointer types internally. Both Howard and Pablo agree that this is the intent. Further, it is necessary for containers to be stored, for example, in shared memory with an interprocess allocator (the type of scenario that allocators are intended to support).

In spite of the (possible) agreement on intent, it is necessary to make this explicit:

An implementations may like to store the result of dereferencing the pointer (which is a raw reference) as an optimization, but that prevents the data structure from being put in shared memory, etc. In fact, a container could store raw references to the allocator, which would be a little weird but conforming as long as it has one by-value copy. Furthermore, pointers to locales, ctypes, etc. may be there, which also prevents the data structure from being put in shared memory, so we should make explicit that a container does not store raw pointers or references at all.

History
Date User Action Args
2019-01-20 16:20:00adminsetmessages: + msg10284
2018-06-22 06:38:21adminsetmessages: + msg9971
2018-06-22 06:38:21adminsetstatus: lewg -> open
2014-11-24 15:11:58adminsetstatus: nad future -> lewg
2011-08-18 17:55:31adminsetmessages: + msg5872
2011-08-18 17:55:31adminsetstatus: deferred -> nad future
2011-03-24 15:58:06adminsetmessages: + msg5682
2011-03-24 15:58:06adminsetstatus: new -> deferred
2010-10-26 20:16:35adminsetmessages: + msg5152
2010-10-26 20:16:35adminsetmessages: + msg5151
2010-10-16 00:00:00admincreate