Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-14 13:52:44

At 09:32 AM 8/12/2003, David Abrahams wrote:

>> 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?
>You're already making paths unfamiliar by "genericizing" them.

The generic path syntax was chosen to be a subset of the "Uniform Resource
Identifiers (URI) : Generic Syntax", RFC-2396. Because that syntax is used
in Internet URL's, it has become familiar to millions of people even if
they never used POSIX or Windows.

I'm not necessarily adverse to a different syntax. Several times during
development something better was almost within reach, but I never could
quite carry it off.

If you would like to write up a grammar and rules as a more formal
proposal, we can all take a look and judge how it would perform in the
cases we think are important.

>The advantages are:
> 1. You can use familiar terminology - there should be no need to
> throw out the term "absolute" just to meet the expectations of
> Unix programmers who expect all paths beginning with '/' to be
> absolute.

You have conflict with existing practice for one group or another. If all
paths which begin with '/' are complete, that conflicts with the experience
of Windows programmers. If they aren't, that conflicts with the experience
of POSIX programmers.

> 2. The rules for understanding generic path syntax are greatly
> simplified and can be understood without platform-specific
> knowledge.

I'm probably misunderstanding your proposal because it sounds like you are
introducing special rules for the first non-'/' element. A formal proposal
would clarify that.

> 3. Portable/generic paths can actually be portable/generic, as
> advertised. You won't have the problem we have now: no
> complete path that works on a Windows machine can also work on
> a Unix machine (disregarding paths to remote machines, of
> course).

That isn't a problem in practice. The most portable and usually best way to
deal with path completion is the same as with other libraries and
programming languages. The bulk of the program code should always deal only
in terms of relative paths. At some point (based on user input, an
initial_path() default, or the operating system's path completion algorithm
when the platform API is called with relative path arguments), the relative
paths are completed to become the paths actually used in some platform API

Perhaps I should explain that and give some examples in the docs. Perhaps
the point needs to be made more strongly that the Filesystem library isn't
doing any hidden completion manipulation of paths; in the end the native
string just gets passed on to the operating system as is done by all other
I/O libraries I'm aware of.


Boost list run by bdawes at, gregod at, cpdaniel at, john at