24

私が話していることの文脈を示すために、次のプログラムはtrueclang ++/libc ++でコンパイルされたときに正しく出力されます

#include <iostream>
#include <regex>
int main()
{
    std::locale::global(std::locale("en_US.UTF-8"));
    std::wstring str = L"AÀÁÂÃÄÅaàáâãäå";
    std::wregex re(L"[[=a=]]*", std::regex::basic);
    std::cout << std::boolalpha << std::regex_match(str, re) << '\n';
}

std::regex_traits::transform_primary()しかし、私は標準での記述をよく理解できません（これを通じて[=a=]処理されます）。28.7[re.traits]/7 を引用するには:

typeid(use_facet<collate<charT> >) == typeid(collate_byname<charT>)によって返される並べ替えキーの形式が既知であり、主並べ替えキーに変換できる場合collate_byname<charT>::transform(first, last)はそのキーを返し、そうでない場合は空の文字列を返します。

元の提案では、組み込みロケールのファセットがユーザーによって置き換えられていないregex_traits::transform_primary()場合にのみ、標準が機能することが説明されています (これが、結果を等価キーに変換する方法を知ることができる唯一の方法です)。collatecollate::transform()

私の質問は、typeid標準での比較はどのようにそれを保証することになっているのですか? ロケールから引き出されたシステム提供のすべてのファセットが、真の動的タイプをuse_facet持つことを意味しますか?_byname

4

2 に答える 2

1

「私の質問は、標準の typeid 比較はどのようにそれを保証することになっているのですか? use_facet を使用してロケールから引き出されたシステム提供のすべてのファセットが、真の動的タイプとして _byname を持っていることを意味しますか?」

質問の前半に答えるために、 typeid 比較はこれを保証します。ユーザーが の異なる値でテンプレートをインスタンス化した場合use_facet、 typeid 比較は失敗するためです。typeid が一致する場合、ディスパッチされる関数がユーザーによってオーバーライドされていないことが保証されます。したがって、システムの collat​​e_byname クラスを取得し、適切な変換が呼び出されます。

あなたの質問の2番目の部分に答えるために、正規表現で使用されると予想されるロケールに関連付けられたシステム提供のすべてのファセットがこの実装要件に準拠していることを意味します。28.7 への引用文献を引っ張った場所から、同じ文書の前の方で見つけてください。

std::locale に関して transform_primary を実装する移植可能な方法がないことにも注意してください。 std::collat​​e_byname<>::transform によって返されるソート キーの形式が既知であり、プライマリ ソート キーに変換できる場合でも、ユーザーは、独自のカスタム std::collat​​e 実装を使用するロケール オブジェクトにインストールすることができ、適切と思われる任意のソート キー形式を使用できます。したがって、transform_primary メンバー関数は、カスタムの特性クラスに使用され、特定のロケールで実装できない場合は例外をスローする必要があります。

要するに、これは、そのタイプ/タイプ ID に期待される (つまり、システムが提供する) 値以外が存在する場合、ユーザーが別のソート キー形式を指定する可能性があるため、結果が予測不能になる可能性があることを示しています。システムが提供する値に固執することで、そのファセットの typeid がわかるため、ソートキーがわかり、予測可能になります。

于 2012-07-21T18:39:01.593 に答える