On Wed, Oct 26, 2011 at 22:47, Beman Dawes <bdawes@acm.org> wrote:
On Wed, Oct 26, 2011 at 6:24 AM, Yakov Galka <ybungalobill@gmail.com> wrote:
Personally I think that boost::filesystem::paths are a sad joke, it's a pity they're heading to the standard. Although the OS-part is definitely good, the way path class is design isn't suitable for paths outside the unix world.
Could you explain that a bit further? Since class path is used all the time for paths outside the Unix world, I'm curious to know what your concerns are.
Give me some time to write a constructive criticism. Some issues I raise below.
you still cannot use long paths
on windows (longer than MAX_PATH), although they are supported by the OS.
There is one ticket outstanding, http://svn.boost.org/trac/boost/ticket/5448, that is somewhat related to PAX_PATH limitations. The objective is to support any path that is acceptable to the operating system, and that includes better support for long paths.
I know this ticket. Your objective is useless. Seems Bjarne is right about the composition of the committee. Have you done a survey among the users of the library? What I do expect is that calling path.native() will return a string ready to be passed to CreateFileW. No worries about long paths, slashes or backslash, relative paths or other per-platform quirks. Currently I must write something like this: path p = get_some_path(); p = system_complete(p); // according to msdn not guaranteed to work for long paths. Fortunately it does in practice. std::wstring q = p.native(); if(starts_with(q, L"\\\\")) q = "\\\\?\\UNC\\" + q.substr(2); else q = "\\\\?\\" + q; // doesn't handle \\.\.... CreateFileW(q.c_str(), ...); The problem is more serious when we observe that the \\?\ and \\.\ syntax is a detail of implementation. For example we DON'T want the user to be able to input a \\.\ path. We also prefer the user to don't see \\?\ at all. In fact there are two path syntaxes on windows: 1) User paths: can have slashes and backslashes. They start with "\\x", "\x", "x:" or "x" (more or less). 2) System paths: only backslashes supported in general, can't be relative, may start with "\\?\" and "\\.\".
Moreover, judging by the last fixes to the library, it looks like Beman wants to shift the burden of this on the user of the library, instead of implementing something that works transparently.
Which fixes are bothering you:-?
I was talking about revision 71157. -- Yakov