diff options
author | Stephan Bergmann <sbergman@redhat.com> | 2015-11-18 13:40:34 +0100 |
---|---|---|
committer | Stephan Bergmann <sbergman@redhat.com> | 2015-11-18 15:20:43 +0000 |
commit | 0b07406f7147b9abbb2095d9e038b13293cb8b10 (patch) | |
tree | a95c8acd61d038fd1c69392f3bd137a95b1574cc /include/cppu | |
parent | 5da50768716fbcb0ffc093ecd588527723109fed (diff) |
Use C++11 char16_t for sal_Unicode
...in LIBO_INTERNAL_ONLY, __cplusplus, non-MSVC case.
It turns out that sal_Unicode happens to not be mangled into any symbols that
make up the stable URE interface, so (for LIBO_INTERNAL_ONLY, at least) we are
free to replace the typedef to sal_uInt16 with a typedef to any integral type
layout-compatible with that. (sal_Unicode does appear in some symbols in sal's
PRIVATE_textenc.1 section, but that is private between the sal and sal_textenc
libraries, so changing those symbols does not require a change of SONAME.)
C++11 chart16_t is the obvious choice (and will ultimately allow using u"..."
to write literals of type array-of-sal_Unicode). Reportedly, char16_t is
supported since GCC 4.4 and Clang 2.9 but will only be available in MSVC 2015.
For plain C, we continue to use sal_uInt16. We could theoretically use C11
char16_t from <uchar.h>, but at least the Mac OS X 10.11 SDK still does not
offer that C11 header.
For MSVC, we continue to use wchar_t (which is actually unsigned short, due to
/Zc:wchar_t-) for now. Potential options there include dropping /Zc:wchar_t-
and using true wchar_t, or using C++11 char16_t once support for MSVC 2013 is
dropped.
Some code needed to be adapted that was written in a way assuming that
sal_Unicode is unsigned short (which indicates that changing sal_Unicode for
non-LIBO_INTERNAL_ONLY would be an ABI change). OUStringBuffer::append can now
differentiate between being called with sal_Unicode (to append a single
character) and erroneously being called with sal_uInt16 (intending to append a
number's textual representation, for which the sal_Int32 overload must be used
instead). Bugs found are 379fe0409e7973b36210cffa3dd1dfd4032f0ecc "Assume that
this code wants to append a number, not a character" and
dc148335a6a438848325f24c49198fba81043279 "Assume this wants to append the
numerical representation."
The GDB support for pretty-printing of sal_Unicode-related data in
solenv/gdb/libreoffice/sal.py can presumably be simplified now.
Change-Id: I445b3a80e65b7cb004d9e08b38bdc9ee93bc9401
Reviewed-on: https://gerrit.libreoffice.org/20036
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Diffstat (limited to 'include/cppu')
-rw-r--r-- | include/cppu/unotype.hxx | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/include/cppu/unotype.hxx b/include/cppu/unotype.hxx index 2ab7681e61f5..a59445043735 100644 --- a/include/cppu/unotype.hxx +++ b/include/cppu/unotype.hxx @@ -149,6 +149,14 @@ cppu_detail_getUnoType( ::typelib_TypeClass_UNSIGNED_SHORT); } +#if LIBO_INTERNAL_ONLY && (!defined SAL_W32 || defined __MINGW32__) + // cf. sal/types.h sal_Unicode +inline css::uno::Type const & +cppu_detail_getUnoType(SAL_UNUSED_PARAMETER sal_uInt16 const *) { + return cppu::detail::getTypeFromTypeClass(typelib_TypeClass_UNSIGNED_SHORT); +} +#endif + inline css::uno::Type const & cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::sal_Int32 const *) { return ::cppu::detail::getTypeFromTypeClass(::typelib_TypeClass_LONG); @@ -186,6 +194,14 @@ cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::cppu::UnoCharType const *) { return ::cppu::detail::getTypeFromTypeClass(::typelib_TypeClass_CHAR); } +#if LIBO_INTERNAL_ONLY && (!defined SAL_W32 || defined __MINGW32__) + // cf. sal/types.h sal_Unicode +inline css::uno::Type const & +cppu_detail_getUnoType(SAL_UNUSED_PARAMETER sal_Unicode const *) { + return cppu::detail::getTypeFromTypeClass(typelib_TypeClass_CHAR); +} +#endif + inline css::uno::Type const & cppu_detail_getUnoType(SAL_UNUSED_PARAMETER ::rtl::OUString const *) { return ::cppu::detail::getTypeFromTypeClass(::typelib_TypeClass_STRING); |