以下のpathクラスについてです。これらが内部で使用する型は環境によって異なるという話です。
- C++17で標準ライブラリに入るstd::filesystem::path
- Boost.Filesystem v3のboost::filesystem::path
これらpathクラスは、内部では文字列でデータを保有しています。この文字列は、実行環境のファイルシステムでネイティブに使用されるエンコーディングとなります。そのため、実行環境によって、使用する文字の型も異なります。Boostの場合、以下のようになっています。
- Windows環境では、wchar_t。
- POSIX環境とその他の環境では、char。
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文字列であるということを書きたかったのでした。
| スポンサード リンク |
この記事のカテゴリ
- C++ ⇒ filesystem::pathの文字の型