>Beman Dawes <[EMAIL PROTECTED]> 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 or writer?
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 correctly.
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 multi-rooted system.
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.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
