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