On Thu, Oct 27, 2011 at 3:04 PM, Yakov Galka <ybungalobill@gmail.com> wrote:
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?
I hear from users of the library regularly. They mirror the rest of the Boost population; very roughly one third use Unix-like systems and two thirds use Windows. Once Microsoft ships the Dinkumware implementation of the library (based on V2) with VC++ 211, the percentage of Windows users will presumably increase.
What I do expect is that calling path.native() will return a string ready to be passed to CreateFileW.
Yes, that's what it does. Regardless of the operating system, the contents of path.native(), or more to the point, path.c_str(), is exactly as was passed into the path originally. That's important in case it is one of the implementation defined strings - it isn't the job of path to adjust the string.
No worries about long paths, slashes or backslash, relative paths or other per-platform quirks.
Right.
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(), ...);
If you have to write any of that, it is a bug in the library implementation. That's the point of http://svn.boost.org/trac/boost/ticket/5448 - to be sure that the odd-ball, implementation defined syntaxes work. Not just for Windows, but for POSIX too.
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.
Who is the "we" here? There was a time very early on in V1 where I though the Filesystem library path should only accept "approved" forms. Users, and a lot of them at that, let me know loud and clear that they didn't want to be nannied. If they passed in a given native string, that's want they wanted to get passed to the operating system. If they passed in a given generic string, that's want they wanted to get passed to the operating system, modulo only any changes absolutely required by the O/S (which means none on either POSIX or Windows).
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 "\\.\".
Yes, and there is no intention for the Filesystem library to intervene if the user gets it wrong, such as by exceeding a maximum length mandated by the operating system or file system.
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.
Ah! So you want to hide the various implementation defined formats? --Beman