filesystem::pathの文字の型

以下のpathクラスについてです。これらが内部で使用する型は環境によって異なるという話です。

これらpathクラスは、内部では文字列でデータを保有しています。この文字列は、実行環境のファイルシステムでネイティブに使用されるエンコーディングとなります。そのため、実行環境によって、使用する文字の型も異なります。Boostの場合、以下のようになっています。

C++17では、もちろんそのような直接的な規定はありません。ただ、同様にWindowsでwchar_t、POSIX環境でcharとなるということが例として記述されています (N4659 30.10.8 Class [fs.class.path]の最後のexample)。

これに関連する型とメンバー関数として、以下のものがあります。

value_type: 上記の文字型です。
string_type: basic_string<value_type>型です。
メンバー関数 const string_type& native() const noexcept;: pathオブジェクトが保有している文字列への参照を返します。
メンバー関数 const value_type* c_str() const noexcept;: pathオブジェクトが保有している文字列へのconstポインタを返します。native().c_str()と同じです。
メンバー関数 operator string_type() const;: 暗黙型変換です。pathオブジェクトが保有している文字列のコピーを返します。Boost版にはありません。
メンバー関数 string_type::size_type size() const noexcept;: pathオブジェクトが保有している文字列の長さを返します。native().size()と同じです。C++17標準ライブラリ版にはありません。

たとえば、WindowsでCreateFileW関数の実引数にpathオブジェクトの値を渡そうという場合、新しい文字列オブジェクトを作って返すwstring()メンバー関数よりも、文字列オブジェクトを作らないc_str()メンバー関数のほうが効率的です。

なんでWindowsだけwchar_tなのかと言えば、OSのAPIがwchar_t（ただしUTF-16）だからですね。Boost Filesystem Version 3 Designで述べられています。そこでUTF-8固定などにならないのがBoostや標準ライブラリらしさと言えるかもしれません。

というわけで、pathクラスは、Windowsだけwchar_t文字列であるということを書きたかったのでした。

スポンサードリンク

イグトランスの頭の中（のかけら）