This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
Section: 27.1 [strings.general] Status: C++11 Submitter: Beman Dawes Opened: 2009-06-22 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [strings.general].
View all issues with C++11 status.
Discussion:
Addresses UK 218
Prior to the introduction of constant expressions into the library,
basic_string elements had to be POD types, and thus had to be both trivially
copyable and standard-layout. This ensured that they could be memcpy'ed and
would be compatible with other libraries and languages, particularly the C
language and its library.
N2349,
Constant Expressions in the Standard Library Revision 2, changed the
requirement in 21/1 from "POD type" to "literal type". That change had the
effect of removing the trivially copyable and standard-layout requirements from
basic_string elements.
This means that basic_string elements no longer are guaranteed to be
memcpy'able, and are no longer guaranteed to be standard-layout types:
3.9/p2 and 3.9/p3 both make it clear that a "trivially copyable type" is required for memcpy to be guaranteed to work.
Literal types (3.9p12) may have a non-trivial copy assignment operator, and that violates the trivially copyable requirements given in 9/p 6, bullet item 2.
Literal types (3.9p12) have no standard-layout requirement, either.
This situation probably arose because the wording for "Constant Expressions in the Standard Library" was in process at the same time the C++ POD deconstruction wording was in process.
Since trivially copyable types meet the C++0x requirements for literal types,
and thus work with constant expressions, it seems an easy fix to revert the
basic_string element wording to its original state.
[ 2009-07-28 Alisdair adds: ]
When looking for any resolution for this issue, consider the definition of "character container type" in 3.10 [defns.character.container]. This does require the character type to be a POD, and this term is used in a number of places through clause 21 and 28. This suggests the PODness constraint remains, but is much more subtle than before. Meanwhile, I suspect the change from POD type to literal type was intentional with the assumption that trivially copyable types with non-trivial-but-constexpr constructors should serve as well. I don't believe the current wording offers the right guarantees for either of the above designs.
[ 2009-11-04 Howard modifies proposed wording to disallow array types as char-like types. ]
[ 2010-01-23 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]
Proposed resolution:
Change General 27.1 [strings.general] as indicated:
This Clause describes components for manipulating sequences of any
literalnon-array POD (3.9) type. In this Clause such types are called char-like types, and objects of char-like types are called char-like objects or simply characters.