From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-12 07:08:02
At 12:31 PM 8/11/2003, David Abrahams wrote:
>Beman Dawes <bdawes_at_[hidden]> writes:
>> At 07:39 PM 8/10/2003, David Abrahams wrote:
>> >If I were king, the portable, generic version of windows-native
>> >"c:/foo" would be "/c/foo" and the portable generic version of
>> >windows-native "/foo" would be *current_path().begin()/"foo". Is
>> >there a reason that approach was rejected?
>> Yes, it had five or six different problems IIRC, although some of
>> them can be fixed by adding additional syntax. For example, the
>> ambiguity in "/c/foo" - is it a relative path starting with a
>> directory named "c" or a complete path to the c drive
>Read as a generic path according to my system, it is not a relative
>path because it starts with a slash. That's simple and there should
>be no confusion assuming you know you're not looking at a native format..
Can that scheme represent paths which are relative to the root directory of
an unspecified drive? Relative to the current directory of a specified
drive? Can it handle server and share names?
And most important, can it do so in a way that is obvious to a human reader
Schemes which don't supply obvious syntactic markers such as ":" or "//"
for special names are very hard for a human reader or writer to parse
Once syntactic markers and/or rules are introduced, whether to eliminate
ambiguities or to improve readability and writablity, the question is then
what are the advantages of a new and unfamiliar set of markers and/or
rules? The existing operating system syntax and rules are familiar to a
large number of programmers. Even programmers who don't ever work with
multi-rooted file systems often have a passing familiarity with the Windows
rules, which are particularly important as it is the most widely used
In other words, it isn't enough for some competing scheme to work. It has
to have enough advantages to make it worthwhile for programmers to learn
any new syntax or rules.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk