diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2020-09-05 21:45:38 +0200 |
---|---|---|
committer | Stephan Bergmann <sbergman@redhat.com> | 2020-09-07 19:19:14 +0200 |
commit | c927aab29ebfff1ce3ac0b2f27ae343025a9890c (patch) | |
tree | 4a3c67c6d4f50528dd2363d6b81070e83e02018c /vcl/win/gdi | |
parent | fbcdbfef8664430e15b9429187b58dede992accf (diff) |
Make the OUString ctors taking raw sal_Unicode pointer/non-const array explicit
...and in turn add OUString::operator = and OUString::operator +=
overloads that take a std::u16string_view. Without making the ctors explicit,
the operator overloads would have caused ambiguities when called with raw
sal_Unicode pointers/non-const arrays, as those can convert to both OUString and
to std::u16string_view.
But the std::u16string_view operator overloads will generally be useful when
changing OUStringLiteral similarly to 4b9e440c51be3e40326bc90c33ae69885bfb51e4
"Turn OStringLiteral into a consteval'ed, static-refcound rtl_String", at which
point many existing uses of OUStringLiteral will be replaced with uses of
std::u16string_view.
Implementing this change turned up a need for an operator = overload for
OUStringNumber, which has thus been added. No such need turned up for a
corresponding operator += overload, but which can easily be added when the need
arises.
It also revealed that the operator == overloads between an OUString and a raw
sal_Unicode pointer/non-const array were implemented rather inefficiently,
creating a temporary OUString from the raw argument. Those have been improved.
Preceding commits have already taken care of many dubious or simply unnecessary
implicit uses of the now-explicit OUString ctors. This commit makes explicit
the few remaining reasonable uses. (And in some cases needed to change variable
initialization syntax from using parentheses to using curly braces, to avoid the
most vexing parse issue. And needed to explicitly add OUString ctors from
char16 const[2] string literal lvalues in a conditional expression in
writerfilter/source/ooxml/OOXMLFastContextHandler.cxx that are only necessary
because MSVC apparently still insists on doing array-to-pointer decay there.)
All of this only affects LIBO_INTERNAL_ONLY.
Change-Id: I7ce31162e9be1c3ff3c0bd184a34b535ec56be9e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102098
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Diffstat (limited to 'vcl/win/gdi')
-rw-r--r-- | vcl/win/gdi/salfont.cxx | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/vcl/win/gdi/salfont.cxx b/vcl/win/gdi/salfont.cxx index be55c9df0b40..4dac58aaafb2 100644 --- a/vcl/win/gdi/salfont.cxx +++ b/vcl/win/gdi/salfont.cxx @@ -548,7 +548,7 @@ static FontAttributes WinFont2DevFontAttributes( const ENUMLOGFONTEXW& rEnumFont aDFA.SetSymbolFlag(rLogFont.lfCharSet == SYMBOL_CHARSET); // get the font face name - aDFA.SetFamilyName(o3tl::toU(rLogFont.lfFaceName)); + aDFA.SetFamilyName(OUString(o3tl::toU(rLogFont.lfFaceName))); // use the face's style name only if it looks reasonable const wchar_t* pStyleName = rEnumFont.elfStyle; @@ -558,7 +558,7 @@ static FontAttributes WinFont2DevFontAttributes( const ENUMLOGFONTEXW& rEnumFont if( *p < 0x0020 ) break; if( p < pEnd ) - aDFA.SetStyleName(o3tl::toU(pStyleName)); + aDFA.SetStyleName(OUString(o3tl::toU(pStyleName))); // heuristics for font quality // - opentypeTT > truetype @@ -962,7 +962,7 @@ void WinSalGraphics::GetFontMetric( ImplFontMetricDataRef& rxFontMetric, int nFa wchar_t aFaceName[LF_FACESIZE+60]; if( GetTextFaceW( getHDC(), SAL_N_ELEMENTS(aFaceName), aFaceName ) ) - rxFontMetric->SetFamilyName(o3tl::toU(aFaceName)); + rxFontMetric->SetFamilyName(OUString(o3tl::toU(aFaceName))); rxFontMetric->SetMinKashida(pFontInstance->GetKashidaWidth()); rxFontMetric->ImplCalcLineSpacing(pFontInstance.get()); |