diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2020-09-21 20:48:56 +0200 |
---|---|---|
committer | Stephan Bergmann <sbergman@redhat.com> | 2020-09-21 22:15:56 +0200 |
commit | e79a6a5270d190d6e89a6acf08e22419386d2117 (patch) | |
tree | e5cabdd412d77db160e286fcdf942fce0e68b7d5 /include | |
parent | a2791a8b0de05cec8a94b5bd19a6ff6ee4fd76c5 (diff) |
No need to make the OString(std::string_view) ctor explicit
<https://gerrit.libreoffice.org/c/core/+/101829>
"Make std::u16string_view -> OUString construction explicit" (which has
meanwhile been abandoned) had intended to make the OUString(std::u16string_view)
ctor explicit, mostly not for the rationale given in the commit message there
(it being "a rather expensive operation"), but rather to avoid anticipated
ambiguity issues when introducing e6dfaf9f44f9939abc338c83b3024108431d0f69 "Turn
OUStringLiteral into a consteval'ed, static-refcound rtl_uString"---but which
has ultimately been added in a form that did not give rise to such ambiguity
issues after all.
4b9e440c51be3e40326bc90c33ae69885bfb51e4 "Turn OStringLiteral into a
consteval'ed, static-refcound rtl_String" had added the
OString(std::string_view) ctor as explicit to match the corresponding explicit
OUString(std::u16string_view) from the above
<https://gerrit.libreoffice.org/c/core/+/101829>. But as that has now been
abandoned, there is no good reason to keep this ctor explicit, either.
Change-Id: I05742de5f3992ad5995149631bf8d55c8d448387
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103124
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Diffstat (limited to 'include')
-rw-r--r-- | include/rtl/string.hxx | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/include/rtl/string.hxx b/include/rtl/string.hxx index e59ffba83a62..7086de15c987 100644 --- a/include/rtl/string.hxx +++ b/include/rtl/string.hxx @@ -304,7 +304,7 @@ public: #endif #if defined LIBO_INTERNAL_ONLY - explicit OString(std::string_view sv) { + OString(std::string_view sv) { if (sv.size() > sal_uInt32(std::numeric_limits<sal_Int32>::max())) { throw std::bad_alloc(); } |