Boost logo

Boost :

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

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.


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