As per the boost documentation char is used on unix systems for boost::filesystem::path internal value type. But on linux the following code compiles and also works properly.
const std::wstring &m_blobStore;
boost::filesystem::path dir(m_sharePath.begin(), m_sharePath.end());
cout<<dir.string(); // prints the value stored as wstring.
Expectation is that if the m_blobStore has been string instead of wstring only then it should work on linux machines. Can this behaviour be relied on.
Under the path constructor section in the documentation you find:
template <class InputIterator> path(InputIterator begin,
InputIterator end, const codecvt_type& cvt=codecvt());
Effects: Stores the contents [begin,end) or source in pathname. If the contents are in the generic format and the generic format is unacceptable to the operating system's API, they are converted to the native format. [Note: For ISO/IEC 9945 and Windows implementations, the generic format is already acceptable as a native format, so no generic to native conversion is performed. --end note]
Remarks: If the value type of [begin,end) or source is not value_type, conversion is performed by cvt.
So it accepting a wstring is correct per documentation and it'll be converted to value_type internally.
See this part of the documentation.
value_type is an implementation-defined typedef for the character type used by the operating system to represent pathnames.
Member functions described as returning const string, const wstring, const u16string, or const u32string are permitted to return const string&, const wstring&, const u16string&, or const u32string&, respectively.
This is implementation defined.
