"Rainer Deyke" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "Rainer Deyke" <[EMAIL PROTECTED]> 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
>> string.
>
> 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
>>> dangerous.
>>
>> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
