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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
