It's less clear what should happen when the library calls append or assign with iterators whose value_type is char on something whose value_type is wchar_t, which is what you seem to be doing.
std::filesystem requirements[2] actually restrict Source arguments to std string types, iterators (read: pointers) to C-style strings and arrays of characters (which are interpreted as C-style strings).
Yes. That sounds right. It looks like boost::filesystem is matching the
behavior of std;:filesystem now, even if more restrictive (
https://godbolt.org/z/5WYYce6v8).
Boost.URL shouldn't use it and that's for the best, since std::filesystem
doesn't support it either.
Non-contiguous ranges that dereference to char work with both std:: and
boost::filesystem if we use the `append(InputIterator begin, InputIterator
end)` overload.
I think that's the source of confusion here. What C++ says about the
`append(Source const& source)` overload is even more misleading.
(2) and (3) participate in overload resolution only if Source and path are
not the same type, and either:
- Source is a specialization of std::basic_string
https://en.cppreference.com/w/cpp/string/basic_string or
std::basic_string_view
https://en.cppreference.com/w/cpp/string/basic_string_view, or
- std::iterator_traits
http://en.cppreference.com/w/cpp/iterator/iterator_traits
If you're assigning a list to a path, most likely you are doing something wrong.
Yes. `append(InputIterator begin, InputIterator end)` would still allow the person to do this wrong thing though. And `append(InputIterator begin, InputIterator end)` doesn't look like it's always wrong. Two obvious use cases could be (i) appending paths from resource trees or (ii) some std::ranges::view::... that transforms the input into the chars to represent a path segment for that input. If `append(InputIterator begin, InputIterator end)` is not wrong, it looks like `append(Source const& source)` would not be less wrong when Source is just the range holding the iterators for the first overload. In any case, both are still dangerous. Boost.URL and other libraries shouldn't count on it. As Peter mentioned, things like wstring and u16string could be appended, but the semantics will probably be wrong. They will convert char by char, without regards of encoding. Thank you for the explanation. Em seg., 15 de ago. de 2022 às 14:24, Andrey Semashev via Boost < boost@lists.boost.org> escreveu:
On 8/15/22 20:14, Alan de Freitas via Boost wrote:
Assigning or constructing a path from e.g. std::list<char> doesn't make much sense,
Why not?
Because list is not a string. If you're assigning a list to a path, most likely you are doing something wrong.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Alan Freitas https://github.com/alandefreitas