Re: [boost] boost::filesystem file restrictions

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-08-16 11:55:23

At 08:46 PM 8/14/2003, Walter Landry wrote:

 >"Peter Dimov" <pdimov_at_[hidden]> 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?
 >
 >I agree, if only because I could imagine manipulating a bunch of
 >non-legal paths before actually using a legal one.

I gave that some thought during the initial design. Let's say you want to 
do some manipulation of an element (that is, a name representing a node in 
the tree). Perhaps you have a home grown runtime macro expansion scheme. 
You are probably better off holding the data in a std::string until your 
manipulations (say macro expansion) have progressed to the point it is a 
valid native or portable name or path. At that point, assign the string to 
a boost::filesystem::path.

 >  We still have to
 >solve the problem, but at a different place.

Yes, exactly.

 >  Beman's singleton stack
 >seems like a reasonable solution.  We can argue over what the default
 >portability policy should be, but it almost becomes irrelevant because
 >it is easy to change and forget about it.

I've been turning that solution over and over in my mind, and while it has 
some mild blemishes, it seems clearly a big improvement over the current 
design.

Among side advantages, it doesn't break any current code. So unless someone 
comes up with a killer argument against the stack approach, I'll implement 
it within a day or two.

Part of the difficulty with the current approach is documentation; I'll try 
to rectify that in the process.

--Beman