On Tuesday 01 July 2008 15:54:42 Beman Dawes wrote:
The remove(p) function is currently specified to return a bool with a value of exist(p) before the post-condition is established. The post-condition is !exists(p).
The original thought in providing this was that the return value might be useful and would cost nothing.
It turns out that providing this return value does have several costs:
<snip>
Comments?
I'm not sure why that exists check is done at all. In POSIX at least, remove() fails with specific errno value when the to be removed file does not exist. If the boost::filesystem::remove() semantics want to throw in any error except the "file does not exist" one when it will return a "false" then shouldn't it instead be checking for the errno value for this? Of course if the other platforms do not have something like this then just make remove return void. Also, POSIX errno ENOENT does not exactly mean that the file to be removed does not exist but that "the complete path given to the file" does not exist (which also may mean that some component on the path does not exist). From my point of view, whenever I would check for remove() status if the file that I wanted to be removed existed or not also includes this case so the POSIX semantics are fine with me but probably pretty different from other platforms.
PS: This was precipitated by ticket #1972, but doesn't affect the resolution of the remove() issue it raises. That will be fixed for 1.36.0 regardless.
Goodie, someone is solving #1972, thank you :) -- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST