Date: Wed, 14 Aug 2019 22:51:37 -0400
On 8/14/19 1:58 PM, Thiago Macieira wrote:
> This means that using MSVC with the /utf-8 option is the only sane
> alternative, but it's not the default.
>
I've been arguing that the /utf-8 option is almost never the right
option to use since this sets both the source and execution character
encodings and Microsoft does not yet support UTF-8 as the
(run-time/system/native) execution encoding. I recommend use of
/source-charset:utf-8 instead (and perhaps /execution-charset:ascii to
ensure that encoded literals have the same meaning across all supported
(run-time/system/native) execution encodings). Use of either
/source-charset or /execution-charset will implicitly enable
/validate-charset which will cause the compiler to issue a warning if a
character cannot be encoded in the (presumed) execution encoding.
Tom.
> This means that using MSVC with the /utf-8 option is the only sane
> alternative, but it's not the default.
>
I've been arguing that the /utf-8 option is almost never the right
option to use since this sets both the source and execution character
encodings and Microsoft does not yet support UTF-8 as the
(run-time/system/native) execution encoding. I recommend use of
/source-charset:utf-8 instead (and perhaps /execution-charset:ascii to
ensure that encoded literals have the same meaning across all supported
(run-time/system/native) execution encodings). Use of either
/source-charset or /execution-charset will implicitly enable
/validate-charset which will cause the compiler to issue a warning if a
character cannot be encoded in the (presumed) execution encoding.
Tom.
Received on 2019-08-15 04:51:40