Beman Dawes wrote:
That still leaves the question of single path vs separate path and wpath classes. A single path class looks very good in a lot of ways but we still have to decide how to deal with this case on a dual narrow/wide O/S: path p( "foo" ); p /= L"bar";
How about a rule that if any portion of a path is wide, the entire path gets converted to wide?
It's either that, or preserving the original width (thickness?). I'm not sure which is better, but see below.
What about directory iteration? Is that wide or narrow? Don't directory_iterators have to come as two types, narrow and wide?
With a path+wpath design, it's the user's choice. Iterating over a path returns a narrow iterator, and iterating over a wpath returns a wide iterator. With a single path, we have two options. Do as above, or choose a preferred character type whenever the library needs to return a path to the user (that may or may not vary depending on the filesystem the path points to.) In the latter case, it makes sense to make operator/= preserve the width of the returned path; presumably the library had its reasons to choose one over the other. See, I was right about the single path design creating more problems. ;-) path+wpath looks almost trivial in comparison.