问题
Many developers and library authors have been struggling with compile-time strings for quite a few years now - as the standard (library) string, std::string, requires dynamic memory allocation, and isn't constexpr.
So we have a bunch of questions and blog posts about how to get compile-time strings right:
- Conveniently Declaring Compile-Time Strings in C++
- Concatenate compile-time strings in a template at compile time?
- C++ Compile-Time string manipulation
- (off-site) Compile-time strings with constexpr
We've now learned that not only is new available in constexpr code, allowing for dynamical allocation at compile-time, but, in fact, std::string will become constexpr in C++20 (C++ standard working group meeting report by Herb Sutter).
Does that mean that for C++20-and-up code we should chuck all of those nifty compile-time string implementations and just always go with std::string?
If not - when would we do so, and when would we stick to what's possible today (other than backwards-compatible code of course)?
Note: I'm not talking about strings whose contents is part of their type, i.e. not talking about the equivalent of std::integral_constant; that's definitely not going to be std::string.
回答1:
It depends on what you mean by "constexpr string".
What C++20 allows you to do is to use std::string within a function marked constexpr (or consteval). Such a function can create a string, manipulate it, and so forth just like any literal type. However, that string cannot leak out into non-constexpr code; that would be a non-transient allocation and is forbidden.
The thing is, all of the examples you give are attempts to use strings as template parameters. That's a similar-yet-different thing. You're not just talking about building a string at compile-time; you now want to use it to instantiate a template.
C++20 solves this problem by allowing user-defined types to be template parameters. But the requirements on such types are much more strict than merely being literal types. The type must have no non-public data members and the only members are of types that follow those restrictions. Basically, the compiler needs to know that a byte-wise comparison of its data members represents an equivalent value. And even a constexpr-capable std::string doesn't work that way.
But std::array<char, N> can do that. And if you are in constexpr code, call a constexpr function which returns a std::string, and store that string in a constexpr value, then string::size() is a constexpr function. So you can use that to fill in the N for your array.
Copying the characters into a constexpr array (since it's a constexpr value, it's immutable) is a bit more involved, but it's doable.
So C++20 solves those problem, just not (directly) with std::string.
来源：https://stackoverflow.com/questions/57129245/will-stdstring-end-up-being-our-compile-time-string-after-all