So just add a new function (or a parameter to the old function) that doesn't guarantee the "succeeds or has no effect" rule. Alternately you could make the new behavior have the new name but it seems like you want the "default/standard" version to have the guarantee. On Aug 18, 2004, at 7:31 AM, Victor A. Wagner Jr. wrote:
Adding exception safety in the "succeeds or has no effect" to copy_file certainly seem like reasonable suggestion. It adds a small complication of creating a temporary file first, but I'd say it was generally worth it. Note that _could_ change the behavior of some programs that are correctly functioning now in very limited "file space" and make them inoperative.
At Wednesday 2004-08-18 05:19, you wrote:
At Tuesday 2004-08-17 17:16, you wrote:
On Tue, Aug 17, 2004 at 02:40:14PM -0700, Delfin Rojas wrote:
Hi Carlo,
I just wanted to point out native_file_string is part of boost::filesystem::path and copy_file and rename_file (actually called rename) are part of boost::filesystem (operations.hpp).
I am aware of that. The point is that I had a need to rewrite
On Tue, Aug 17, 2004 at 11:55:22PM -0700, Victor A. Wagner Jr. wrote: them.
That seems to indicate that the boost implementation is flawed.
perhaps you could enlighten us further? "doesn't work" is a lousy bug report "flawed" isn't a lot better.
My problem is that Beman is not here. It seems to make little sense to try to convince people when in the end nobody is going to make changes to boost when he is not here.
But I can tell you what I improved of course. Lets start with just one case.
boost::filesystem::copy_file starts with truncating the target file - and when an error occurs, it throws - but STILL did truncate the target file (assuming it already existed) (the exception at the bottom of the function).
This is not how I want exceptions to work; when an exception is thrown from a function then nothing must have been changed - as if the exception is thrown at the start of the function.
My implementation of copy_file either succeeds completely or doesn't do anything: it is atomic.
I need this for robustness. I don't write applications that '"Oops" some error occured - sorry, your configuration file was erased - no there is no backup, I was trying to make one namely'. I have a gard my reputation to write robust and bug free code ;).
The other changes are mostly also related to the need for a better defined post-condition in case of errors.
-- Carlo Wood
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users