basic_string
and basic_string_view
Section: 27.2 [char.traits], 27.4.3.2 [string.require], 27.3.3 [string.view.template] Status: WP Submitter: Gennaro Prota Opened: 2017-07-03 Last modified: 2023-11-22
Priority: 3
View all other issues in [char.traits].
View all issues with WP status.
Discussion:
basic_string
and basic_string_view
involve undefined behavior in a few cases where it's
simple for the implementation to add a static_assert
and make the program ill-formed.
Traits::char_type
shall be the same asCharT
.
Here, the implementation can add a static_assert
using the is_same
type trait. Similar issues exist in 27.4.3.2 [string.require] and, for
basic_string_view
, in 27.3.3 [string.view.template]/1.
[2017-07 Toronto Tuesday PM issue prioritization]
Priority 3; need to check general container requirements
Partially by the adoption of P1148 in San Diego.
Tim opines: "the remainder deals with allocator value type mismatch, which I think is NAD."
Previous resolution [SUPERSEDED]:
This wording is relative to N4659.
Edit 27.2 [char.traits] as indicated:
-3- To specialize those templates to generate a string or iostream class to handle a particular character container type
CharT
, that and its related character traits classTraits
are passed as a pair of parameters to the string or iostream template as parameterscharT
andtraits
. IfTraits::char_type
shall be the sameis not the same type asCharT
, the program is ill-formed.Edit 27.4.3.2 [string.require] as indicated:
-3- In every specialization
basic_string<charT, traits, Allocator>
, ifthe typeallocator_traits<Allocator>::value_type
shall name the same typeis not the same type ascharT
, the program is ill-formed. Every object of typebasic_string<charT, traits, Allocator>
shall use an object of typeAllocator
to allocate and free storage for the containedcharT
objects as needed. TheAllocator
object used shall be obtained as described in 23.2.2 [container.requirements.general]. In every specializationbasic_string<charT, traits, Allocator>
, the typetraits
shall satisfy the character traits requirements (27.2 [char.traits]). If, and the typetraits::char_type
shall name the same typeis not the same type ascharT
, the program is ill-formed.Edit 27.3.3 [string.view.template] as indicated:
-1- In every specialization
basic_string_view<charT, traits>
, the typetraits
shall satisfy the character traits requirements (27.2 [char.traits]). If, and the typetraits::char_type
shall name the same typeis not the same type ascharT
, the program is ill-formed.
[2023-05-15; Jonathan Wakely provides improved wording]
As noted above, most of this issue was resolved by P1148R0.
The remainder is the change to make it ill-formed if the allocator has the wrong
value_type
, but since P1463R1 that is already part of
the Allocator-aware container requirements, which apply to basic_string
.
[2023-06-01; Reflector poll]
Set status to Tentatively Ready after eight votes in favour during reflector poll.
There was a request to editorially move the added text in Note 1 into Note 2 after this is approved.
[2023-06-17 Approved at June 2023 meeting in Varna. Status changed: Voting → WP.]
Proposed resolution:
This wording is relative to N4950.
Edit 27.4.3.2 [string.require] as indicated:
-3-
In every specializationEvery object of typebasic_string<charT, traits, Allocator>
, the typeallocator_traits<Allocator>::value_type
shall name the same type ascharT
.basic_string<charT, traits, Allocator>
shall use an object of typeAllocator
to allocate and free storage for the containedcharT
objects as needed. The In every specializationbasic_string<charT, traits, Allocator>
, the typetraits
shall satisfy the character traits requirements (27.2 [char.traits]).[Note 1: Every specialization
basic_string<charT, traits, Allocator>
is an allocator-aware container, but does not use the allocator’sconstruct
anddestroy
member functions (23.2.2 [container.requirements.general]). The program is ill-formed ifAllocator::value_type
is not the same type ascharT
. — end note][Note 2: The program is ill-formed if
traits::char_type
is not the same type ascharT
. — end note]