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 portability checking.
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.