From: David Abrahams (dave_at_[hidden])
Date: 2003-08-25 20:48:16
"Rainer Deyke" <rainerd_at_[hidden]> writes:
> David Abrahams wrote:
>> "Rainer Deyke" <rainerd_at_[hidden]> writes:
>>> David Abrahams wrote:
>>>> A single component of a path is still a path, and it
>>>> shouldn't devolve into a string.
>>> I disagree. While a path with just one component can exist, a
>>> single path component is no more a path than an element in an array
>>> of integers is itself an array of integers.
>>> A single component of a path is a name, and therefore naturally
>>> represented by 'std::string'.
>> Are you seriously saying that path("foo") is not a path?
> No. "foo" is a path element. path("foo") is a path with one element.
>> If you want
>> to make paths into containers of strings, give them iterators and
>> operator, and I'll accept the name back() as a way to get the leaf
> Paths already have iterators to iterate over the path elements. I agree
> that 'back' would be a better name what is currently called 'leaf', since
> this frees the 'leaf' name to return a path instead of a string.
>>> If 'p' is a native path
>> Is there such a thing as a "native path"? I thought all path strings,
>> even if they began as native, got converted immediately into some
>> "portable generic" format internally.
> It is my understanding that paths are implemented as
> std::vector<std::string> or something similar, where the individual
> strings can contain slashes if the underlying filesystem allows it.
> It would be a shame if filesystem::path was unable to represent
> legal native paths just because they contain characters which have
> special meaning in the portal path grammar.
>>> then 'p.leaf()' may contain any character that is supported by the
>>> native file system, which may include slashes. When 'p.leaf()' is
>>> then converted back into a 'filesystem::path', the resulting path
>>> will have different sematics than intended. This strikes me as very
>> Oh, is that what happens now? Yipes!
> Yipes indeed.
I am finding Rainer's arguments quite convincing. Beman, what do you
think about this?
Also, his last point makes me think that perhaps path ought to have
push_back so we can *add* an element with a slash in it.
If a path really *is* a container of strings, I have no problem with
having functions which build paths by parsing strings in various ways,
but it seems like those functions don't belong in the path
constructor. What about, simply:
struct path : std::vector<std::string>
// forwarding constructors
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk