Re: [boost] Re: path::leaf()

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
 >>>> 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