Re: [boost] boost::filesystem file restrictions

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-16 11:33:06

At 04:23 PM 8/15/2003, Peter Dimov wrote:
 >Beman Dawes wrote:
 >> At 01:40 PM 8/14/2003, Peter Dimov wrote:
 >>  >
 >>  >I am not sure that it should be the responsibility of the path
 >>  class to >enforce some notion of portability. Wouldn't it be more
 >>  appropriate to >defer the portability check, if any, to the point
 >>  where the path is >actually used in a filesystem operation?
 >>
 >> That's too late. A real path is often made up of some native elements
 >> (which the portability check doesn't apply to) and some portable
 >> elements (which the portability check should be applied to).
 >>
 >> The earlier the error can be detected, the better. Also, a path is
 >> only constructed once, but may be use multiple times.
 >
 >[...]
 >
 >> That would be easy if we accepted the native platform as the default,
 >> and portable cases had to be specially coded. But my interest is in
 >> portable semantics as the default.
 >
 >I must be missing something. What is a "portable" path useful for? A
 >portable path _grammar_ (element sequence separated by '/') is certainly
 >useful, it allows me to write portable _code_ that deals with paths.

Yes, to the extent the elements (the names) are portable.

 >Portable path _data_ is a different story.

For sure. But we have been talking only about names which are elements of 
paths and how to string them together via a portable grammar. We haven't 
been talking about file data content at all.

--Beman