This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofResolved status.
char_traits specializations should declare theirlength(),compare(), andfind() members constexprSection: 27.2.4[char.traits.specializations]Status:ResolvedSubmitter: Jeffrey YasskinOpened: 2012-12-24Last modified: 2020-09-06
Priority:Not Prioritized
View all otherissues in [char.traits.specializations].
View all issues withResolved status.
Discussion:
Addresses ES 14, US 19
These functions have easy recursive constexpr implementations that, unfortunately, aren't efficient at runtime. EWG is still figuring out how to solve this problem in general (e.g.,N3444 isn't sufficient to avoid stack overflows in debug builds or to get the optimal assembly-based implementations at runtime), so users can't portably solve this problem for themselves, but implementations can use compiler-specific techniques to choose the right implementation inside their standard libraries.
The LWG is still undecided about whether individual implementations can add constexpr to these functions, so we need to addconstexpr to the standard here for implementations to be able to improve this.
[2013-03-15 Issues Teleconference]
Moved to Open.
There are a number of people who have a strong interest in this issue not available for the telecon.
It also plays at the heart of a discussion about library freedoms forconstexpr and specifyinga library that may depend on unspecified compiler intrinsics to be implementable.
[2013-09 Chicago]
Moved to NAD Future.
While it is clear that this feature can be implemented using only C++14constexpr features,there is real concern that we cannot call the efficient, highly optimized, C implementations of thesefunctions under a C++14constexpr implementation, nor implement similar ourselves as thistypically involves use of inlineasm instructions.
Clang and libc++ have some experience of using intrinsics to try to address the performance issue, butthe current intrinsics are not general enough to supportchar_traits. The intrinsics supportonly operations on character string literals, and the string literal is no longer visibleas aliteral after passing as aconst char * to thechar_traits functions.
Additional concern was raised that these operations are unlikely to be useful anyway, as the only clientisbasic_string which relies on dynamic memory allocation, and so cannot effectively be made aliteral type. Jeffrey then pointed out the pendingstring_view library that will also usechar_traits and would most certainly benefit from being a literal type.
Given the choice of giving up performance on a critical library component, or requiring a compilerintrinsic with only unsuccessful implementation experience, the consensus is to not reject this, unlesscompelling implementation experience is demonstrated. NAD Future seems the appropriate resolution.
[2017-06-02 Issues Telecon]
Resolved byP0426R1, adopted in Issaquah.
Proposed resolution:
This wording is relative to N3691.
In 27.2.4.2[char.traits.specializations.char], [char.traits.specializations.char16_t], [char.traits.specializations.char32_t], and 27.2.4.6[char.traits.specializations.wchar.t]:
staticconstexpr int compare(const char_type* s1, const char_type* s2, size_t n);staticconstexpr size_t length(const char_type* s);staticconstexpr const char_type* find(const char_type* s, size_t n, const char_type& a);