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