問題タブ [string-view]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++ - 一般化された container_view の代わりに string_view を使用する理由?
新しい C++17 標準の string_view は少し冗長であることがわかりました。
データを callee に渡すための単純なメカニズムの非常に冗長なコレクションがあり、オーバーヘッドはあまりなく、1 つのコンテナー タイプにのみ固有のメカニズムがもう 1 つあります。
この機構を文字列のみに提供し、他のコンテナーにはより一般化された型を提供しない理由がわかりません。賢明な答えの 1 つは、この種のソリューションは既にあるということです。たとえば、C++17 以降のプレゼンテーションでは、string_view は として説明されていobserver_ptr<T> (or T*) for stringます。
C++17 で導入された string_view とは対照的に、より一般的な container_view に対する引数を述べてください。
c++ - boost::spirit::x3 を使用して std::string から boost::string_view に解析する
私の以前の質問では、ディレクティブを使用してboost::spirit::x3解析することでパーサーのパフォーマンスを改善できることが示唆されました。boost::string_viewraw
ただし、コンパイルするのに苦労しています。これは私が見つけたものです：
以前は、ディレクティブを処理する
x3ために特殊化する必要がありましたassign_to_attribute_from_iterators(たとえば、この SO の回答を参照)。rawx3move_to代わりに free 関数を使用するようになりました (たとえば、この SO answerを参照してください)。
したがって、move_toから解析すると機能するオーバーロードを追加しましたchar*：
ただし、コンパイルされません。
1）を使用して解析する場合std::string::const_iterator
いずれかのコンストラクターは、または をboost::string_view想定しています。const char*std::string&
boost::string_viewfromをインスタンス化するにはどうすればよいstd::string::const_iteratorですか?
2)オーバーロードboost/spirit/home/x3.hppの前に含まれている場合move_to
オーバーロードが選択されないのはなぜですか? で定義されているものよりも優れたオーバーロードではありませんboost/spirit/home/x3/support/traits/move_to.hppか? 含める順序に関係なく、オーバーロードが選択されていることを確認するにはどうすればよいですか?
c++ - null で終わらない char 配列の std::string_view のサイズの違い
さまざまなコンパイラでstd ::string_view をいじっていましたが、null 以外で終了する char 配列でstd::string_viewを初期化するときに、各コンパイラが異なるサイズを出力することに気付きました。
すべてのコンパイラは、最適化をオンにすると正しいサイズを出力しますが、最適化をオフにすると間違ったサイズを出力するようです (どちらの場合も正しいサイズを出力する GCC を除く)。
私の質問は次のとおりです。なぜそうなのですか？
コード：
出力: Visual C++ 19.00.24619.0
出力: Clang 4.0.0-r282394 (MinGW-w64 を使用)
出力: GCC 6.2.0 (MinGW-w64)