On Tue, Aug 31, 2004 at 08:40:03AM -0400, David Abrahams wrote:
My most important analysis of practical use of paths from a portable point of view was that an absolute path should be considered to be _always_ native - hard coded in a type. But not necessarily the other way around (a non-absolute path can still be native as well).
I know you hate to answer such questions, but what problems does that solve?
Portability robustness of code. I've given numerous of examples in the meantime in other posts.
From my post of 30 Aug 2004 (two posts earlier in this thread, you even replied to it):
Correct would be for example: #ifdef BOOST_WINDOWS fs::native_path root("C:/cygwin"); #else // ... #endif fs::native_path np = root / "usr/src"; if (exists(np)) // Ok and the fact that this should throw: fs::native_path np("/usr/src"); // Note, not possible to use fs::relative_path here (would throw). if (exists(np)) // Should throw on cygwin (with BOOST_WINDOWS) // because the path is not complete! Compare that with the current implementation: #ifdef BOOST_WINDOWS fs::path root("C:/cygwin"); #else // ... #endif fs::path np = root / "usr/src"; if (exists(np)) // Ok Now we 'forget' to use the 'root' there: fs::path np = "/usr/root"; if (exists(np)) // Returns 'false' rather than throwing. The fact that it is possible to make a mistake like that comes from the fact that the current implementation doesn't enforce a truely portable "relative_path" type, but allows one to use any "path value" for fs::path "variables" and (ab)use them anywhere regardless. The only way to catch the above mistake without introducing a new type would be to test inside fs::exists that the path that is being passed is complete - and if not, demand that it is relative. But that would be kludge and not attack the REAL problem at the root.
The naming fs::native_path is essential thus and should not be confused with a fs::absolute_path, that I did not propose.
Hm.
Note that the current implementation doesn't use the word 'absolute' - it speaks of 'complete'. I take those two as the same in this discussion. Of course it would be possible to introduce another level of paths and call that 'complete_path' - which would be forced to be complete - or make itself complete at construction if possible. However, I don't see must use for that - because it seems better, more flexible, to delay that completion until the path is actually being passed to a system call. So, your proposal only would make sense to me if you would not allow automatic conversion to a complete path (ie: fs::complete_path("foo") would throw) so that this type would be complete at all times. But well, what does that solve? }:-) -- Carlo Wood <carlo@alinoe.com>