Re: [boost] filesystem/path behavior

From: David Abrahams (dave_at_[hidden])
Date: 2006-04-20 11:36:57

Walter Landry <wlandry_at_[hidden]> writes:

> me22 <me22.ca_at_[hidden]> wrote:
>> On 4/19/06, Walter Landry <wlandry_at_[hidden]> wrote:
>> > Both of these options make the user learn about things that they
>> > should not have to learn about.  Just get rid of default checking.  If
>> > people want to ensure that all paths that pass through their program
>> > will be valid on some arbitrary set of filesystems, then they can set
>> > that themselves.  The filesystem library should not be my nanny.
>> >
>> 
>> The library, however, /should/ make the default thing the right thing,
>> as it does now.
>
> It is _not_ doing the right thing.  It is giving errors for valid
> paths.  It adds complexity to codes that don't need it.  The code that
> started this thread should have worked.
>
>> I think a better option would be to add " If you don't know why this
>> path is invalid, read
>> http://boost.org/libs/filesystem/doc/portability_guide.htm#name_check%AD_functions
>> " to the exception's .what() message in debug mode.
>
> This still makes people learn about path checking when they should not
> have to.  Don't make me think.

100% agreed.  If the filesystem library is going to be useful for
operating on real filesystems, it has to operate on real paths without
making the programmer jump through hoops.  The reality is that the
actual paths we need to deal with are in general _not_ portable across
all systems, and 99% of them are dictated by existing constraints of
the filesystem or installed software and data, rather than being
conjured from whole cloth by C++ programmers using the filesystem
library.

Taking out this checking is long overdue.  If it were a compile-time
check, I'd find it annoying and limiting -- which is bad enough -- but
the fact that it's a runtime check makes it error-prone and likely to
fail at the worst time.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com