Re: [boost] Filesystem portable path rationale and use-cases

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-21 10:20:59

At 03:35 AM 8/19/2003, Yitzhak Sapir wrote:

 > ... numerous use cases ...
 >
 >My feeling from all these examples is that a path string is inherently
 >specific to the system for which it was specified, and can't really be
 >ported to anywhere else.  Much like a string is usually inherently 
specific
 >in its encoding to the system-specified encoding.  However, the 
filesystem
 >library can provide a portable way to manipulate this system specific 
path,
 >much like the string library provides a portable way to manipulate the
 >system-specific encoded string.  In view of this, why try for a "portable 

 >path" at all?

There are plenty of use cases where no name portability checking is 
required. Some require checking for the generic grammar, but do not require 
checking for portable names. There are two variations on not checking for 
portable names; (1) doing no checking at all (in class path, which amounts 
to deferring the checking to the operations function calls where the O/S 
API will do the checking), and (2) doing native checking.

All of you examples fall into those categories.

Then there are a number of use cases which do require some degree of name 
checking.

The plan for the filesystem library is to support all of the use cases, 
including the ones you identify. The most serious remaining questions have 
to do with defaults. But regardless of how those defaults turn out, all of 
the use cases will be supported one way or another.

Thanks,

--Beman