On Mon, Feb 15, 2016 at 05:57:25PM +0100, Stephan Bergmann wrote:
yeah, I mentioned the le/be variant to be 'complete', I will certainly
concede that it would likely be overkill.
still having sal_utf16. sal_utf32 and even sal_utf8 would not hurt,
especailly comapred to sal_Int32, sal_Unicode, sal_Char respectively
Instead of introducing yet more typedefs, we'll more and more move to C++11
char16_t, char32_t (which already started, now that sal_Unicode is a typedef
for char16_t, for non-WNT LIBO_INTERNAL).
That would be my preference as well, so what about replacing internal
uses of sal_Unicode with char16_t?
Regards,
Khaled
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.