Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk