https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111351
Jiang An <de34 at live dot cn> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |de34 at live dot cn
--- Comment #2 from Jiang An <de34 at live dot cn> ---
> This will result in user code which can be built or not based on whether
> their string happens to fit within the SSO string length. I find that quite
> unfortunate, since it is supposed to be an internal implementation
> detail/optimization, and this makes it effectively part of the API that code
> will grow to depend on.
This comes from the nature of SSO and constexpr variables. I don't think it
worthwhile to revert this PR (https://github.com/microsoft/STL/pull/1735) for
MSVC STL - which makes the codes harder to understand and slows down the
compilation.
> As comparison, libc++ rejects all the above examples, by forcing the SSO-size
> to zero in constant evaluation context, so that a pointer to an external
> allocation is always used.
libc++ is, unfortunately, currently unable to implement constexpr SSO, IIUC. I
failed to find a constexpr-compatible way to determine libc++'s std::string is
in short mode if the short mode were enabled in constant evaluation. (As a
result, libc++'s string always uses long mode during constant evaluation.)
https://github.com/llvm/llvm-project/blob/0954dc3fb9214b994623f5306473de075f8e3593/libcxx/include/string#L829-L837
Note that there's no tag outside of the union, so we can't know which variant
member is active without causing constant evaluation failure - unless the
mechanism of std::is_within_lifetime (https://wg21.link/p2641r4) gets
implemented.
