Compile failures with char8_t by MSVC under /std:c++latest(C++20) mode
We've stumbled across some build failures in Wt after implementing support for char8_t under /std:c++latest(C20) in the development version of Visual C++. Could you help look at this? Thanks in advance! Noted that this issue only found when compiles with unreleased vctoolset, that next release of MSVC will have this behavior.
Wt requires boost. You can get boost 32bits and 64bits from following address and Change the install path:
- open VS2017 x86 Native tools command tool
- git clone https://github.com/emweb/wt d:\Wt\src
- cd D:\Wt
- mkdir build_x86 && pushd build_x86
- cmake -G "Visual Studio 15 2017" -DCMAKE_SYSTEM_VERSION=10.0.17134.0 -DBOOST_PREFIX=C:\boost_1_67_0\x86 -DBOOST_LIBRARYDIR=C:\boost_1_67_0\x86\lib32-msvc-14.1 ..\src\
- msbuild /m /p:Configuration=Release;Platform=Win32 ALL_BUILD.vcxproj /t:Rebuild
D:\Wt\src\test\utf8\Utf8Test.C (22): error C2440: 'initializing': cannot convert from 'const char8_t ' to 'std::basic_string<char,std::char_traits,std::allocator>'
D:\Wt\src\test\utf8\Utf8Test.C (22): note: No constructor could take the source type, or constructor overload resolution was ambiguous
D:\Wt\src\test\utf8\Utf8Test.C (145): error C2440: 'initializing': cannot convert from 'const char8_t ' to 'std::basic_string<char,std::char_traits,std::allocator>'
D:\Wt\src\test\utf8\Utf8Test.C (145): note: No constructor could take the source type, or constructor overload resolution was ambiguous
D:\Wt\src\test\utf8\Utf8Test.C (157): error C2665: 'Wt::utf8': none of the 2 overloads could convert all the argument types
D:\Wt\src\src\Wt/WString.h(778): note: could be 'Wt::WString Wt::utf8(const std::string &)'
D:\Wt\src\src\Wt/WString.h(772): note: or 'Wt::WString Wt::utf8(const char *)'
D:\Wt\src\test\utf8\Utf8Test.C (157): note: while trying to match the argument list '(const char8_t )'
Updated by Roel Standaert over 4 years ago
I see. The C++20 standard proposal is kind of breaking backwards compatibility there. This may go rather deep, so we'll have to see what we should do there. It would make sense that
std::u8string instead of
std::string, for example. Then there's all of the use cases where we use a
WString not for
i18n purposes (
WString::tr and friends), but only because that implies UTF-8 encoding. It would make sense to take a
std::u8string from C++20 on, instead.