>"Rainer Deyke" <[EMAIL PROTECTED]> 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 >>>> 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?
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 safely.
>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.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
