From 028b2f31400ea7fdfacf77f5ca459633aa18eda4 Mon Sep 17 00:00:00 2001
From: Beman Dawes
Why base the generic-path string format on POSIX?
-
-POSIX is the basis for the most familiar path-string formats, including the
+
Why base the generic-path string format on POSIX?
+POSIX is the basis for the most familiar path-string formats, including the URL portion of URI's and the native Windows format. It is ubiquitous and familiar. On many systems, it is very easy to implement because it is either the native operating system format (Unix and Windows) or via a @@ -23,6 +22,14 @@ POSIX library (z/OS, OS/390, and many more.)
Several early versions did require users to identify each path as a file or directory path, and this seemed to increase errors and decrease code readability. There was no apparent upside benefit. +Why do some path member function names have a "system_specific_" prefix?
+To alert users that the results are inherently non-portable. The names are +deliberately ugly to discourage use except where really necessary.
+Why doesn't path supply operator== and other comparison operators?
+There is no way to know if two path objects actually represent the +same path. For example, path("/foo") and path("../foo") may +represent the same path, even though they are textually different. +path::string()'s can be used for textual comparison.
Why not support a concept of specific kinds file systems, such as posix_file_system or windows_file_system.
Portability is one of the one or two most important requirements for the @@ -153,10 +160,7 @@ conditions for error are very different between the source and the target.
detection were evaluated, including at least four complete implementations. While the details for rejection differed, they all tended to distort the otherwise simple design of the rest of the library. -Why do some path member function names have a "system_specific_" prefix?
-To alert users that the results are inherently non-portable. The names are -deliberately ugly to discourage use except where really necessary.
© Copyright Beman Dawes, 2002
Revised -20 November, 2002
\ No newline at end of file +26 November, 2002 \ No newline at end of file diff --git a/doc/path.htm b/doc/path.htm index 4da9960..0a5888d 100644 --- a/doc/path.htm +++ b/doc/path.htm @@ -179,11 +179,11 @@ ensure names in paths are as portable as desired, but they must be explicitly called by the user.Naming Rationale: Class path member function names and operations.hpp non-member -function names are chosen to be distinct from one another. Otherwise, given a -path foo, for example, both foo.empty() and empty( foo ) -would be valid, but with completely different semantics. Avoiding this was -considered more important than consistency with some C++ Standard Library naming -conventions, which aren't followed uniformly anyhow, even in the standard.
+function names were chosen to be somewhat distinct from one another. The +objective was to avoid both foo.empty() and empty( foo ) being +valid, but with completely different semantics. At one point path::empty() +was renamed path::is_null(), but that caused many coding typos because +std::string::empty() is often used nearby.Several path non-member functions return representations of m_name in formats specific to the operating system. These formats are implementation @@ -603,7 +603,7 @@ efficient, and less error prone.
© Copyright Beman Dawes, 2002
Revised -24 November, 2002
+26 November, 2002