string_view
は、C++ Library Fundamentals TS( N3921 )内で提案された機能で、C++ 17に追加されました
私が理解している限り、それはある種の文字列「概念」を表すタイプであり、文字列として表示可能なものを格納できるあらゆるタイプのコンテナのビューです。
const std::string&
パラメータタイプはstring_view
になりますか?string_view
について考慮すべき別の重要なポイントはありますか?ありとあらゆる種類の「文字列参照」および「配列参照」提案の目的は、すでに別の場所に所有されており、非変更ビューのみが必要なデータのコピーを避けることです。問題のstring_view
はそのような提案の1つです。 string_ref
およびarray_ref
と呼ばれる初期のものもありました。
アイデアは常に、最初の要素へのポインタといくつかの既存データ配列または文字列のサイズのペアを格納することです。
このようなビューハンドルクラスは、値によって安価に渡すことができ、安価なサブストリング操作を提供します(単純なポインターのインクリメントとサイズ調整として実装できます)。
文字列の多くの用途では、実際に文字列を所有する必要はありません。また、問題の文字列は多くの場合、すでに他の人が所有しています。したがって、不要なコピーを回避することで効率を向上させる真の可能性があります(保存できるすべての割り当てと例外を考えてください)。
元のC文字列は、nullターミネータが文字列APIの一部であるという問題に悩まされていたため、基になる文字列(la strtok
)を変更しないと部分文字列を簡単に作成できませんでした。 C++では、これは長さを個別に保存し、ポインターとサイズを1つのクラスにラップすることで簡単に解決できます。
私が考えることができるC++標準ライブラリの哲学からの1つの大きな障害と相違点は、そのような「参照ビュー」クラスが標準ライブラリの他の部分と完全に異なる所有権セマンティクスを持っていることです。基本的に、標準ライブラリの他のものはすべて無条件に安全で正しいものです(コンパイルする場合は正しいです)。このような参照クラスでは、それはもはや真実ではありません。プログラムの正確さは、これらのクラスを使用するアンビエントコードに依存します。そのため、確認したり教えたりするのは難しいです。