読んだもの P0254R0: Integrating std::string view...

8
稲葉 一浩

Transcript of 読んだもの P0254R0: Integrating std::string view...

Page 1: 読んだもの P0254R0: Integrating std::string view …「標準ライブラリの他のstd::string引数も置換えたい」 この部分を C++17 に入れるべきか? 既存のオーバーロードを消して置き換える形にするとABI互換性が

稲葉 一浩

Page 2: 読んだもの P0254R0: Integrating std::string view …「標準ライブラリの他のstd::string引数も置換えたい」 この部分を C++17 に入れるべきか? 既存のオーバーロードを消して置き換える形にするとABI互換性が

この前の Library Fundamentals TS で入ったstd::string_view についての改善案 ◦ おさらい: string_view とは何か

だいたいこういう実装になるであろう物体

「文字列を渡して欲しいが引数を std::string と const char* のどちらにするか迷う」時のお助け用の型

template<typename CharT> class basic_string_view { public: // std::basic_string っぽいインターフェイス private: CharT *begin, *end; };

Page 3: 読んだもの P0254R0: Integrating std::string view …「標準ライブラリの他のstd::string引数も置換えたい」 この部分を C++17 に入れるべきか? 既存のオーバーロードを消して置き換える形にするとABI互換性が

現在 TS として受理されている案

namespace std { class string_view { public: string_view(const char*); string_view(const std::string&); std::string to_string() const; }; // std::string には変更なし }

簡単のため basic_string_view<Char

T, ...> を string_view 等と略記しています

Page 4: 読んだもの P0254R0: Integrating std::string view …「標準ライブラリの他のstd::string引数も置換えたい」 この部分を C++17 に入れるべきか? 既存のオーバーロードを消して置き換える形にするとABI互換性が

P0254R0

namespace std { class string_view { public: string_view(const char*); }; class string { public: explicit string(std::string_view sv); operator std::string_view() const; } }

string_view の側では std::string を 特別扱いしない

Page 5: 読んだもの P0254R0: Integrating std::string view …「標準ライブラリの他のstd::string引数も置換えたい」 この部分を C++17 に入れるべきか? 既存のオーバーロードを消して置き換える形にするとABI互換性が

P0254R0

namespace std { class string { public: string& insert(size_t i, std::string_view sv); string& replace(size_t i, size_t n, std::string_view sv); ... } }

string でなく string_view を取れば済む

メソッドはそうする

Rationale: null終端文字列や、他のライブラリの文字列型

(QString, CString) を効率的に渡せる

Page 6: 読んだもの P0254R0: Integrating std::string view …「標準ライブラリの他のstd::string引数も置換えたい」 この部分を C++17 に入れるべきか? 既存のオーバーロードを消して置き換える形にするとABI互換性が

P0254R0 : Future Work

標準ライブラリの他のstd::string引数も置換えたい ◦ 例 std::logic_error や std::runtime_error

◦ 置き換えたくないもの

std::iftream, std::ofstream のファイル名引数

これらは結局 OS の API に渡る可能性が高く、null終端の保証がないstring_viewで受け取るのは非効率

Page 7: 読んだもの P0254R0: Integrating std::string view …「標準ライブラリの他のstd::string引数も置換えたい」 この部分を C++17 に入れるべきか? 既存のオーバーロードを消して置き換える形にするとABI互換性が

「標準ライブラリの他のstd::string引数も置換えたい」 ◦ この部分を C++17 に入れるべきか?

既存のオーバーロードを消して置き換える形にするとABI互換性が

かといって単にstring_view版を増やすと曖昧性増えないか

fstream のケース(前ページ) どうするのか

const char* を string_view にすると長さ求める分遅くなることが

◦ こんなややこしい議論を今さらC++17向けに始めるべきではない、C++<next> でやろう派

vs

◦ そんなことでは標準としての consistency が無くなる派

Page 8: 読んだもの P0254R0: Integrating std::string view …「標準ライブラリの他のstd::string引数も置換えたい」 この部分を C++17 に入れるべきか? 既存のオーバーロードを消して置き換える形にするとABI互換性が

[22cp00:07169] Re: [isocpp-lib] [isocpp-lib-ext] P0254 - Integrating string_view into the standard library

[22cp00:07196] [Ext] Coherence in the standard ◦ Library TS として提案されたものはspec本体には手を加えないという不文律だか決まりがあって今回のようなことになりやすい

◦ 「TSからの昇格であってもC++次期バージョンの2-meeting前には“feature freeze”する決まりとすべきでは」

◦ H.Sutter:「Suggestion: If anyone wants to see a new feature (core or fundamental library) applied in the standard library as a precondition of the basic feature going into the standard, please speak up early and say so, so we can discuss it and find out whether people generally agree. If there is a consensus for requiring that, then the “applying it to the standard library” part should be part of the proposal’s development.」