From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-26 14:12:57
At 09:48 PM 8/25/2003, David Abrahams wrote:
>"Rainer Deyke" <rainerd_at_[hidden]> writes:
>> 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?
When this was discussed in the past, one suggested solution was to
represent slashes via an escape mechanism. That's the approach RFC2396
takes. The other suggestion was to treat slashes like '\0'; just ban them.
But that discussion never went anywhere since it isn't an issue for the
current POSIX/Windows implementation.
I'm certainly in agreement that before adding implementations for any file
or operating systems that would have that problem we have to deal with it
>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
I really don't view a path as a container of strings, at least not to the
point of being willing to publicly derive from std::vector<std::string>. A
container of strings seems a really useful conceptual model for how a path
might store data internally. That conceptual model has helped answer
various questions that were really troublesome before the model. But the
intent was always to hand-tailor the actual interface to make it easy to
write the kinds of code envisioned as the typical uses of the library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk