On Fri, Jan 06, 2012 at 07:13:00PM -0200, ext Thiago Macieira wrote: > On Friday, 6 de January de 2012 21.27.20, David Faure wrote: > > Exception handling is a new argument though. But doesn't the current QFile > > have the exact same issue then? You start writing, throw an exception, dtor > > calls close, there you go. The use of an internal temporary file doesn't > > change this at all, so I don't see why it should behave differently. > > The file will be closed no matter what, unless you allow for the file > descriptor > to leak. And even if it were to leak, the writing was already done and has > appeared on disk. > > That's very different from executing a rename upon closure. Up until that > point, any observers of the file have not seen any change. Then they do and > see > an in-progress change being saved. > i agree with that.
> No, whatever this class is, close() without commit() means "rollback". > that would make it pointless to have this as a built-in feature of qfile, because the api would be inconsistent anyway (qfile => close, qsavefile => commit). anyway, i don't buy the exception argument. i don't see why the d'tor needs to continue calling close() - it can call rollback() instead just as well. for non-safe qfiles this is the same as close(), so existing behavior doesn't change. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
