Re: [boost] [filesystem] windows/posix inconsistencies.

Subject: Re: [boost] [filesystem] windows/posix inconsistencies.
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2012-02-06 11:38:02

Hi Beman,

I have been thinking about the interface exposed by Boost.Filesystem a 
little. As I said earlier, I base my experience on trying to write 
portable code that runs on both windows and **nux, at a minimum.

I sympathetic to the view that the most efficient underlying 
representation must be used, but I'm not convinced we can have that
100% while making the interface portable and easy to use.

Therefore I think the main interface should focus on being portable,
and if someone want to optimize stuff, they can dig into the native
parts of the API.

Recoomandation 1: Make two typedefs: string_type and native_string_type
where the first is portable and the second is not.

Recommendation 2: the default sting constructor should take an 
std::string and assume this contains utf8 unless the system does not 
support it; then it simple assume the native code-page. This implies 
that windows code neeed to convert to utf16 in this constructor.
(The same can be said about other constructors/append; the presence of 
these constructors makes it harder to write portable code).

Recommendation 3: if users wants to go native, which means non-portable 
by default, it might be more explicit to add path::fromNativeString(...)
to create a path this way.

Remark 1: the interface for string is quite hard to grasp, and I fail 
to see why it's needed. There are 11 functions!

Recommendation 4: remove the c_str() function, it can easily be called 
from a string return.

Recommedation 5: the interface only needs 2-4 string functions:

   string_type string() const;   // perhaps with different OS return type
   const native_string_type& native_string() const;

The first will return in utf8, thus requiring a conversion on e.g. 
windows; the second is not-portable, but guaranteed to require no 
conversion, The first converts \ to /, the second does not.

Recommendation 6: for efficiency, comparison operators
can be overloaded for one argument of the type string_type and 
native_string_type.

just my 2 cents

kind regards

Thorsten