[Boost-users] filesystem path{}.string() interface brittle when developing cross platform

Subject: [Boost-users] filesystem path{}.string() interface brittle when developing cross platform
From: Werner Erasmus (werasm_at_[hidden])
Date: 2016-06-03 04:04:27

Firstly, I would like to than the author/s of filesystem for their great
work and their time.

I've recently written some code on Linux where I had to adapt a
filesystem::path object to string. I noticed that the return value was of
type [const std::string&], and used the same return value in my getter that
exposed the underlying string. Moving over to windows, I had strange
crashes (undefined behaviour) as result of the type under windows being
converted to [std::string]. The reason for the "undefined behaviour" took
me a while to figure out.

While understanding why the author returned by value (Windows API
underlying type not a std::string...), I think that for a specific type,
the contract concerning return value "semantics" should no be broken. There
is a significant difference between returning by const reference as opposed
to returning by value. If the contract cannot be held, the decision should
be made to (in the interest of consistency/clarity) to return the same type
for all OS's/platforms if the code is to be considered platform
independent. This might mean to compromise by returning by value, or to, in
the case of Windows (where the underlying string has a different type),
cache the string, or at the very least document a *BOLD* note that caution
must be taken.

I can comprehend that if conversion is required, return by value is the
only option. I expect type consistency per type, as this to me is part of
the contract of a function.

I don't consider this a bug, but would appreciate some response.

Kind Regards