Связь между 'x' и L'x 'и расширением (' x ')

Пусть x - любой член базового набора символов источника. 'x' и L'x' являются членами базового набора символов выполнения и набора символов широкого исполнения, соответственно.

Верно ли, что интегральные значения 'x' и L'x' должны быть равны? Похоже, что стандарт не требует этого, что имеет смысл. Можно, по-видимому, использовать EBCDIC в качестве узкой кодировки и Unicode как широкую кодировку.

Верно ли, что std::use_facet<std::ctype<wchar_t>>(std::locale()).widen('x') должно быть равно L'x' в некоторой (или какой-либо) локали? В этом случае имеет смысл потребовать этого, но я не могу найти такое требование и в стандарте. Аналогично, std::use_facet<std::ctype<wchar_t>>(std::locale()).narrow(L'x') совпадает с 'x'?

Если вышеуказанное не верно, то какой из этих

std::wcout << L'x';
std::wcout << ct.widen('x');

должен выводить x? ct является подходящей фасеткой языка.

Ответ 1

На практике практически невозможно гарантировать широкие наборы символов, поскольку стандарты C и С++ требуют, чтобы все широкие символы могли быть представлены с одним значением кодирования, тогда как стандартом в программировании Windows был широко распространенный текст в формате UTF-16, Первоначально широкоформатный текст Windows был просто оригинальным 16-разрядным Unicode, теперь называемым UCS-2, который по-прежнему используется в Windows-консолях Windows и соответствует требованиям C и С++. UTF-16 является расширением UCS-2, которое использует два значения кодирования, называемых суррогатной парой, для символов вне исходного Unicode Basic Multilingual Plane, a.k.a. BMP.

" Верно ли, что интегральные значения 'x' и L'x' должны быть равны? [Когда x является членом набора символов исходного кода С++]

Основной набор символов источника - это подмножество ASCII, и почти все существующие кодировки общего характера, включая, в частности, кодировки Unicode, являются расширениями ASCII. Существует одно исключение, а именно кодирование символов IBM EBCDIC (существует несколько вариантов). Однако, если он все еще используется вообще, то это на мэйнфреймах IBM.

Таким образом, на практике у вас есть эта гарантия, но в формальном виде у вас ее нет. Что еще более важно, однако, это нерелевантный. Например, в базовом наборе исходных символов отсутствует знак $, который вы вряд ли можете ожидать обойтись, т.е. Ограничение себя базовым набором символов источника не является практическим предложением.

" Верно ли, что std::use_facet<std::ctype<wchar_t>>(std::locale()).widen('x') должно быть равно L'x' в некоторой (или любой) локали [Когда x является членом набора символов исходного кода С++]

По той же причине, что и для литералов, да на практике нет в формальном (поскольку поддерживаются кодировки, такие как EBCDIC), а также это не имеет отношения к практическому специалисту.

В частности, для практического использования более важным является то, что Microsoft Visual С++ имеет (недокументированный) Windows ANSI в качестве его набора символов исполнения, а UTF-16 - как широкую кодировку символов. Например. на моей машине набор символов выполнения - Windows 1252, a.k.a. Windows ANSI Western. И некоторые символы, в частности, имеют совершенно разные коды символов Юникода. Хуже того, может быть только некоторый узкий набор символов, который можно было бы использовать как набор символов выполнения, где кодировка UTF-16 какого-либо символа использовала бы суррогатную пару значений кодирования. И в этом случае widen не может даже представить результат; там нет места.