Movatterモバイル変換

This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofC++17 status.

2447. Allocators andvolatile-qualified value types

Section: 16.4.4.6[allocator.requirements]Status:C++17Submitter: Daniel KrüglerOpened: 2014-10-16Last modified: 2017-07-30

Priority:4

View otheractive issues in [allocator.requirements].

View all otherissues in [allocator.requirements].

View all issues withC++17 status.

Discussion:

According to Table 27 — "Descriptive variable definitions" which is used to define the symbols used in theallocator requirements table within 16.4.4.6[allocator.requirements] we have the following constraints forthe typesT, U, C:

any non-const object type (3.9)

This wording can be read to allow instead avolatile-qualified value type such asvolatile int.

The nearest-by way of fixing this would be to add "non-volatile" as additional constraint to this tablerow.

Another choice would be to think of requiring that allocators must be capable to handle anycv-qualifiedvalue types. This would make all currently existing allocators non-conforming that can't handlecv-qualified value types, so I'm not suggesting to follow that route.

A less radical step would be to allowcv-qualified types just forC (which is used to specify thefunctionsconstruct anddestroy and where does not even exist any requirement thatC actually is related to the value type of the allocator at all). This seemingly extension would be harmless because as of p8 of thesame sub-clause "An allocator may constrain the types on which it can be instantiated and the arguments for which itsconstruct member may be called."

This differs from the requirements imposed on the typesT andU which both refer to value types of allocators.

The proposed wording attempts to separate the two classes of requirements.

Previous resolution [SUPERSEDED]:

This wording is relative to N4140.

1. Change 16.4.4.6[allocator.requirements], Table 27 — "Descriptive variable definitions", as indicated:

   Table 27 — Descriptive variable definitions

   Variable	Definition
   T, U, C	any non-constconst and non-volatile object type (3.9)
   C	any object type
   …

2. Change 16.4.4.6[allocator.requirements] p8 as indicated: (This wording change is intended tofix an obvious asymmetry betweenconstruct anddestroy which I believe is not intended)

   -8- An allocator may constrain the types on which it can be instantiated and the arguments for which itsconstructordestroy members may be called. If a type cannot be used with a particular allocator, the allocator class or the call toconstructordestroy may fail to instantiate.

[2014-11, Urbana]

JW: say "cv-unqualified" instead?
JW: very nervous about allowing construct on const-types, because of the cast to (non-const)void*
MA: should we just make the minimal fix?
STL: don't breakC out for special treatment
New proposed resolution: just change "non-const" to "cv-unqualified". Keep addition ofdestroy later.

[2015-02 Cologne]

GR: It makes me nervous that someone at some point decided to not add "non-volatile".
AM: That was over ten years ago. It was a deliberate, minuted choice to supportvolatile. We are now reversing that decision. It would be good to poll our vendors, none of which are in the room. This is a bit more work than we expect of a P0 issue.
VV: libstdc++ and libc++ seem to supportvolatile template parameters for the standard allocator.
AM: To clarify, the proposed resolution here would remove the requirement to supportvolatile. Implementations could still choose to supportvolatile.
DK: I'm happy to drop this and open a new issue in regard to thedestroy member specification.
AM: I just think this is harder than a P0. Let's reprioritize.

[2015-04-01 Daniel comments]

The less controversial part of the issue related to constraints imposed ondestroy has be handed over to the new issue2470⁽ⁱ⁾.

[2015-05-06 Lenexa: Move to Ready]

Proposed resolution:

This wording is relative to N4431.

1. Change 16.4.4.6[allocator.requirements], Table 27 — "Descriptive variable definitions", as indicated:

   Table 27 — Descriptive variable definitions

   Variable	Definition
   T, U, C	anynon-constcv-unqualified object type (3.9)
   …