On Fri, Jan 25, 2013 at 6:30 PM, Beman Dawes <bdawes@acm.org> wrote:
[...] Not particularly elegant, but this does work:
path x("/foo/bar"); path y("/foo/baar");
auto result = std::mismatch(x.begin(), x.end(), y.begin());
path prefix; for (auto itr = x.begin(); itr != result.first; ++itr) prefix /= *itr;
std::cout << prefix << std::endl;
This code doesn't work on windows, as I described in my previous post.
Why should paths be so different from everything else? I think, if the design is actually right, some rationale is sorely needed.
Also,
* (**) the docs don't say what the value_type of path::iterator is. A string value? A range that becomes invalid when the path is destroyed? Ah!?! How surprising; inspecting the code shows it iterates over paths! A container whose element type is itself is very unusual!
It is a kludge to deal with the type of the contained string being implementation defined and not necessarily the type the user wants. In other words, a misuse of path to supply string interoperability. The returned type should ideally be a basic_string, with begin() and end() templatized on the string details, but I didn't think of that until recently.
Well, in this particular issue no-one said that iterator::value_type must be a string. Let it be a path_element, since (--end()).extension() still seems to be useful. (Or maybe let extension() be a free-standing function operating on arbitrary strings?) As per "string being implementation defined", you must already know my opinion. This is a bad design choice. A non-templatized path means shoving the user a concrete character encoding and memory allocation scheme. Now, please follow the following argument: The rationale for using the "native" encoding is that it is supposed to be frequently passed to/from the system, and therefore supposedly being inefficient if done otherwise. *But* the high-level path operation that are (supposed to be) provided by boost::path are usually done in a higher-level code. Now, if I use narrow UTF-8 strings in my code, then there will be more UTF-8 → UTF-16 → UTF-8 conversions (on windows) than actual calls to the system. Therefore, it is more logical to let the user choose when she likes to do the conversion to the system encoding (if at all) and provide a narrow boost::path as it has been in Boost.FSv2. Cheers, -- Yakov