From Jason Turner

[fs.path.cvt]

Diff to HTML by rtfpessoa

Files changed (1) hide show
  1. tmp/tmphuhy6w4r/{from.md → to.md} +100 -0
tmp/tmphuhy6w4r/{from.md → to.md} RENAMED
@@ -0,0 +1,100 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ #### `path` conversions <a id="fs.path.cvt">[[fs.path.cvt]]</a>
2
+
3
+ ##### `path` argument format conversions <a id="fs.path.fmt.cvt">[[fs.path.fmt.cvt]]</a>
4
+
5
+ [*Note 1*:
6
+
7
+ The format conversions described in this section are not applied on
8
+ POSIX-based operating systems because on these systems:
9
+
10
+ - The generic format is acceptable as a native path.
11
+ - There is no need to distinguish between native format and generic
12
+ format in function arguments.
13
+ - Paths for regular files and paths for directories share the same
14
+ syntax.
15
+
16
+ — *end note*]
17
+
18
+ Several functions are defined to accept *detected-format* arguments,
19
+ which are character sequences. A detected-format argument represents a
20
+ path using either a pathname in the generic format (
21
+ [[fs.path.generic]]) or a pathname in the native format (
22
+ [[fs.def.native]]). Such an argument is taken to be in the generic
23
+ format if and only if it matches the generic format and is not
24
+ acceptable to the operating system as a native path.
25
+
26
+ [*Note 2*: Some operating systems may have no unambiguous way to
27
+ distinguish between native format and generic format arguments. This is
28
+ by design as it simplifies use for operating systems that do not require
29
+ disambiguation. An implementation for an operating system where
30
+ disambiguation is required is permitted to distinguish between the
31
+ formats. — *end note*]
32
+
33
+ Pathnames are converted as needed between the generic and native formats
34
+ in an operating-system-dependent manner. Let *G(n)* and *N(g)* in a
35
+ mathematical sense be the implementation’s functions that convert
36
+ native-to-generic and generic-to-native formats respectively. If
37
+ *g=G(n)* for some *n*, then *G(N(g))=g*; if *n=N(g)* for some *g*, then
38
+ *N(G(n))=n*.
39
+
40
+ [*Note 3*: Neither *G* nor *N* need be invertible. — *end note*]
41
+
42
+ If the native format requires paths for regular files to be formatted
43
+ differently from paths for directories, the path shall be treated as a
44
+ directory path if its last element is a *directory-separator*, otherwise
45
+ it shall be treated as a path to a regular file.
46
+
47
+ [*Note 4*: A path stores a native format pathname (
48
+ [[fs.path.native.obs]]) and acts as if it also stores a generic format
49
+ pathname, related as given below. The implementation may generate the
50
+ generic format pathname based on the native format pathname (and
51
+ possibly other information) when requested. — *end note*]
52
+
53
+ When a path is constructed from or is assigned a single representation
54
+ separate from any path, the other representation is selected by the
55
+ appropriate conversion function (*G* or *N*).
56
+
57
+ When the (new) value *p* of one representation of a path is derived from
58
+ the representation of that or another path, a value *q* is chosen for
59
+ the other representation. The value *q* converts to *p* (by *G* or *N*
60
+ as appropriate) if any such value does so; *q* is otherwise unspecified.
61
+
62
+ [*Note 5*: If *q* is the result of converting any path at all, it is
63
+ the result of converting *p*. — *end note*]
64
+
65
+ ##### `path` type and encoding conversions <a id="fs.path.type.cvt">[[fs.path.type.cvt]]</a>
66
+
67
+ For member function arguments that take character sequences representing
68
+ paths and for member functions returning strings, value type and
69
+ encoding conversion is performed if the value type of the argument or
70
+ return value differs from `path::value_type`. For the argument or return
71
+ value, the method of conversion and the encoding to be converted to is
72
+ determined by its value type:
73
+
74
+ - `char`: The encoding is the native narrow encoding (
75
+ [[fs.def.native.encode]]). The method of conversion, if any, is
76
+ operating system dependent. \[*Note 6*: For POSIX-based operating
77
+ systems `path::value_type` is `char` so no conversion from `char`
78
+ value type arguments or to `char` value type return values is
79
+ performed. For Windows-based operating systems, the native narrow
80
+ encoding is determined by calling a Windows API
81
+ function. — *end note*] \[*Note 7*: This results in behavior
82
+ identical to other C and C++ standard library functions that perform
83
+ file operations using narrow character strings to identify paths.
84
+ Changing this behavior would be surprising and error
85
+ prone. — *end note*]
86
+ - `wchar_t`: The encoding is the native wide encoding (
87
+ [[fs.def.native.encode]]). The method of conversion is unspecified.
88
+ \[*Note 8*: For Windows-based operating systems `path::value_type` is
89
+ `wchar_t` so no conversion from `wchar_t` value type arguments or to
90
+ `wchar_t` value type return values is performed. — *end note*]
91
+ - `char16_t`: The encoding is UTF-16. The method of conversion is
92
+ unspecified.
93
+ - `char32_t`: The encoding is UTF-32. The method of conversion is
94
+ unspecified.
95
+
96
+ If the encoding being converted to has no representation for source
97
+ characters, the resulting converted characters, if any, are unspecified.
98
+ Implementations should not modify member function arguments if already
99
+ of type `path::value_type`.
100
+