From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-10-25 13:10:53
Beman Dawes wrote:
> At 08:45 AM 10/25/2004, Peter Dimov wrote:
>> Beman Dawes wrote:
>>> At 01:10 PM 10/22/2004, Miro Jurisic wrote:
>>>> boost::fs, as far as I understand it, ran into the problem that it
>>>> was impossible to sidestep the invariant.
>>> No, rather than the error check was on by default. Some people want
>>> it off as the default.
>> I interpret it a little differently: the "error" check provided no
>> value to users;
> That's true for some users, but not all users.
Certainly. Think of my statement as integrated over all possible users. Each
user has his own unique needs, but it's still possible to form meaningful
sentences that describe the general case.
>> in fact, it "provided" a negative value, which is why most prefer
>> "off by default".
> Only for the users who don't want to perform the check. For those
> that do want the check, it has a positive value.
I'm afraid I haven't been able to express my point well. My point was that
if you focus on The Check, you'll only conclude that most users don't want
The Check by default. This doesn't mean that most users don't want A Check
by default; it just may not be The Check.
There is a spectrum of possibilities between Strictest Check and No Check
which may contain the optimal default that provides just the right amount of
> You could attribute the preference to the degree of portability
> required by the user's application's but I think it is more than
> that. Some people would rather be safe by default, while others
> would rather error checks only be applied if explicitly invoked.
> That seems like a personal preference to me.
I think that the main problem is that the current checks do not always
signal errors. Errors are never a matter of personal preference, they are
always part of a specification or dictated by external requirements.
Tolerating checks that typically produce a significant amount of false
positives can be a matter of personal preference, of course. But it also
depends on how such checks are implemented. I tolerate a relatively high
degree of false positives in compiler warnings, but I'd rather not see a
similar rate in compiler errors. I certainly wouldn't mind a filesystem
_warning_ for nonportable paths, if we find a suitable delivery mechanism.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk