Jeff Garland wrote:
On Fri, 20 Aug 2004 08:42:03 -0400, David Abrahams wrote
"Jeff Garland"
writes: The only use I can see is that you at run-time can ensure that some application generated paths (e.g. path(root / "mysubdir")) are portable but why base an entire library on such a small thing.
It's a big thing to me.
It's clear there are two usage models, then, because I have the same experience as Martin does. It's unfortunate that the filesystem library is biased towards one model and makes the other one difficult to work with.
I don't consider an extra constructor parameter 'difficult'. Sure, maybe the default should be flipped around -- I'd be fine with that. I give much credit to Beman for listening on this issue because personally I found a large lack of support for handling the portable path issue in languages like 'perl' that supposedly provide good cross-platform libraries.
It is a question of ideology, not of difficulty. The current philosophy of the library tries to protect the user from himself, which is totally at odds with the spirit of C++. "Did you know that your path is valid on the current platform, and (usually) portable to all of the platforms you care about, but not portable according to our overly conservative rules? Here, take that exception and like it!" A "safety mechanism" that 98% of the people turn off as a matter of habit isn't something that increases safety.