Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk