sol2/docs/source/codecvt.rst

std::(w/u16/u32)string support
==============================
because this is surprisingly hard using standard C++
----------------------------------------------------

Individuals using Visual Studio 2015, or on Windows with the VC++ and MinGW compilers (possibly Clang++ on Windows as well) have ``<codecvt>`` headers, and thusly Sol will attempt to include it. Individuals on GCC 4.9.x, Clang 3.5.x, Clang 3.6.x do not seem to have ``<codecvt>`` shipped with the standard library that comes with installation of these compilers. If you want ``std::wstring``, ``std::u16string``, ``std::u32string`` automatic handling then you need to make sure you have those headers and then define ``SOL_CODECVT_SUPPORT`` on unsupported compilers.

ThePhD did not want this to have to be a thing, but slow implementations and such force their hand. When GCC 7.x comes out, ThePhD will consider removing the effect of defining this macro and leaving <codecvt> support in at all times.

GCC 7.x is now out, and its codecvt support seems to work in it as well. We will be removing the conditional SOL_CODECVT support and deprecating support for GCC 4.x.x, Clang 3.5.x, and Clang 3.6.x in releases past sol2 v2.17.5
Turns out C++ sucks when all implementers don't do things equally as fast. WHO KNEW? 2016-08-13 01:08:59 +08:00			`std::(w/u16/u32)string support`
			`==============================`
			`because this is surprisingly hard using standard C++`
			`----------------------------------------------------`

revert codecvt fix for MinGW v7 and greater add docs about compiler support add notes about compilation issues update single 2017-06-08 00:33:59 +08:00			Individuals using Visual Studio 2015, or on Windows with the VC++ and MinGW compilers (possibly Clang++ on Windows as well) have ``<codecvt>`` headers, and thusly Sol will attempt to include it. Individuals on GCC 4.9.x, Clang 3.5.x, Clang 3.6.x do not seem to have ``<codecvt>`` shipped with the standard library that comes with installation of these compilers. If you want ``std::wstring``, ``std::u16string``, ``std::u32string`` automatic handling then you need to make sure you have those headers and then define ``SOL_CODECVT_SUPPORT`` on unsupported compilers.
Turns out C++ sucks when all implementers don't do things equally as fast. WHO KNEW? 2016-08-13 01:08:59 +08:00
[ci skip] be clear in docs about inheritance usage 2016-08-15 00:12:48 +08:00			`ThePhD did not want this to have to be a thing, but slow implementations and such force their hand. When GCC 7.x comes out, ThePhD will consider removing the effect of defining this macro and leaving <codecvt> support in at all times.`
revert codecvt fix for MinGW v7 and greater add docs about compiler support add notes about compilation issues update single 2017-06-08 00:33:59 +08:00
			`GCC 7.x is now out, and its codecvt support seems to work in it as well. We will be removing the conditional SOL_CODECVT support and deprecating support for GCC 4.x.x, Clang 3.5.x, and Clang 3.6.x in releases past sol2 v2.17.5`