>"Peter Dimov" <[EMAIL PROTECTED]> 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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
