Есть ли обновления поддержки локализации в С++ 0x?

Чем больше я работаю с языками языка С++, тем больше я понимаю --- они сломаны.

  • std::time_get - не является симметричным с std::time_put (как в C strftime/strptime) и не позволяет легко разбирать времена с метками AM/PM.
  • я недавно обнаружил, что форматирование простого числа может приводить к незаконному UTF-8 в определенных локалях (например, ru_RU.UTF-8).
  • std::ctype очень упрощен, предполагая, что верхняя/нижняя может быть выполнена на основе каждого символа (преобразование случая может изменить количество символов и зависит от контекста).
  • std::collate - не поддерживает силу сопоставления (чувствителен к регистру или нечувствителен).
  • Невозможно указать часовой пояс, отличный от глобального часового пояса, при форматировании времени.

И многое другое...

  • Кто-нибудь знает, ожидаются ли какие-либо изменения в стандартных гранях в С++ 0x?
  • Есть ли способ принести важность таких изменений?

Спасибо.

EDIT: Разъяснения в случае недоступности ссылки:

std::numpunct определяет разделитель тысяч как char. Поэтому, когда разделитель в U + 2002 - различный вид пространства, он не может быть воспроизведен как одиночный char в UTF-8, а в виде последовательности с несколькими байтами.

В C API struct lconv определяет разделитель тысяч как строку и не страдает от этой проблемы. Таким образом, при попытке форматирования чисел с разделителями вне ASCII с локали UTF-8 создается недопустимый UTF-8.

Чтобы воспроизвести эту ошибку, напишите 1234 на std: ostream с вложенным ru_RU.UTF-8 locale

EDIT2: Я должен признать, что API-интерфейс локализации POSIX C работает намного плавнее:

  • Существует инверсия strftime - strptime (strftime делает то же самое, что и std::time_put::put)
  • Нет проблем с форматированием чисел из-за упомянутой выше точки.

Однако он по-прежнему не может быть совершенным.

EDIT3: В соответствии с последними заметками о С++ 0x я вижу, что std::time_get::get - похожее на strptime и противоположное std::time_put::put.

Ответы

Ответ 1

Я согласен с вами, С++ не имеет надлежащей поддержки i18n.

Кто-нибудь знает, ожидаются ли какие-либо изменения в стандартных гранях в С++ 0x?

В игре слишком поздно, поэтому, вероятно, нет.

Есть ли способ принести важность таких изменений?

Я очень пессимистично отношусь к этому.

Когда его спросили напрямую, Страуструп утверждал, что он не видит никаких проблем с текущим статусом. И еще один из больших ребята С++ (автор книги и все) даже не понял, что wchar_t может быть одним байтом, если вы читаете стандарт.

И некоторые потоки в boost (что, кажется, направляет направление в будущем) показывают малое понимание того, как это работает, что страшно страшно.

С++ 0x едва ли добавил некоторые типы символов символов Юникода, в конце игры и после большой борьбы. Я слишком долго не задерживаю дыхание.

Я предполагаю, что единственный шанс увидеть что-то лучше, если кто-то действительно хороший/уважаемый в мирах i18n и С++ напрямую связан со следующей версией стандарта. Не знаю, кто это может быть: - (

Ответ 2

std::numpunct является шаблоном. Все специализации пытаются вернуть символ десятичного разделителя. Очевидно, что в любой локали, где это широкий символ, вы должны использовать std::numpunct<wchar_t>, поскольку специализация <char не может этого сделать.

Тем не менее, С++ 0x в значительной степени выполняется. Однако, если хорошие улучшения продолжатся, комитет С++, вероятно, начнет С++ 1x. Комитет по стандарту ISO С++, скорее всего, примет вашу помощь, если ее предложит ваша национальная организация-член ISO. Я вижу, что Павел Минаев предложил отчет о дефектах. Это технически возможно, но проблемы, которые вы описываете, - это общие ограничения дизайна. В этом случае наиболее надежным направлением является создание библиотеки Boost для этого, пройти ли она проверку Boost, представить ее для включения в стандарт и принять участие в совещаниях ISO С++ для решения любых возникающих там проблем.