Boost logo

Boost Users :

Subject: Re: [Boost-users] filesystem path{}.string() interface brittle when developing cross platform
From: Sergey Mitsyn (svm_at_[hidden])
Date: 2016-07-05 09:38:21


Sorry for late reply - I just now run accidentally into this thread.

On 03.06.2016 11:04, Werner Erasmus wrote:


> 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.

Documentation says that string() returns by value. In old docs, there is
a remark that string() is allowed to return by reference, depending on

>If string_type is the same type as the function's return type, the
>function is permitted to return by const& rather than const value.
>[Note: For POSIX, this occurs for string(), for Windows, wstring().
>--end note]

Looks like in the new docs (at least in 1.61) the remark is removed.

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

Mitsyn Sergey
Это сообщение проверено на вирусы антивирусом Avast.

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at