[Libreoffice-commits] core.git: Handle wchar_t as native C++11 type on windows
Stephan Bergmann
sbergman at redhat.com
Wed May 4 08:30:00 UTC 2016
The below commit means that internally in LIBO_INTERNAL_ONLY code,
sal_Unicode and sal_uInt16 no longer "clash" (due to being typedefs to
the same underlying type) on any platform. The intent is to switch
sal_Unicode from a typedef of wchar_t to a typedef of char16_t (still
for LIBO_INTERNAL_ONLY only) on the Windows/MSVC platform once we drop
support for MSVC 2013---at which point all platforms will use a typedef
of char16_t for LIBO_INTERNAL_ONLY,
For backward compatibility, non-LIBO_INTERNAL_ONLY remains as it always was:
* For Windows/MSVC, sal_Unicode is a typedef of wchar_t, which, thanks
to /Zc:wchar_t- is a typedef of unsigned short (which is the same
underlying type as sal_uInt16).
* For all other platforms, sal_Unicode is a typedef of sal_uInt16 directly.
The below commit apparently also means that your next Windows build will
likely break due to stale PCH data unless you do a full rebuild.
On 05/03/2016 09:26 PM, David Ostrovsky wrote:
> commit e16fa715c43dcdf836ce8c400b6d54eae87b627d
> Author: David Ostrovsky <david at ostrovsky.org>
> Date: Sun Mar 13 09:18:00 2016 +0100
>
> Handle wchar_t as native C++11 type on windows
>
> The option /Zc:wchar_t- prevented to use wchar_t as a built-in type
> according to the C++ standard. In Visual C++ 6.0 and earlier, wchar_t
> was not implemented as a built-in type, but was declared in wchar.h as
> a typedef for unsigned short. Now, years later after the end of life
> this outdated toolchain, there is no reason not to use native type.
>
> The only issue could be the ABI compatibility. But on a quick look at
> least, it looks like none of the mangled C++ symbols in the stable URE
> interface actually depend on wchar_t.
>
> We forgot to get rid of /Zc:wchar_t- in 5.1. Do that for LibreOffice
> 5.2, though.
>
> Change-Id: I8d6b380660859efa44c83c830734978d31d756a0
> Reviewed-on: https://gerrit.libreoffice.org/22589
> Tested-by: Jenkins <ci at libreoffice.org>
> Reviewed-by: Stephan Bergmann <sbergman at redhat.com>
More information about the LibreOffice
mailing list