On Thu, Jan 19, 2012 at 10:42:28PM +0100, ext David Faure wrote: > Ah, but my "separate class" initial idea was the KDE/QtCreator idea, i.e. a > class that isn't a QFile. So deriving from QFile is a new idea :) > well, creator's savefile is derived from qtemporaryfile, which makes the implementation very elegant. but that's a minor detail.
> B) QFile builtin mode. > Thiago's emails made me realize that this solution is only valid if no > additional API methods are needed (since otherwise we have methods that don't > make sense unless we're in a specific mode, so better put them in a subclass). > But do we still need additional methods? The developer can ask close() to > roll back by simply calling setError() on the file before closing, for errors > that QFile couldn't detect itself. > one could do it that way, yes. but for exception safety this means that the d'tor must signal an error before calling close(). this is actually quite reasonable as such: once the object is gone you can do no error checking, so discard on destruction is the only clean option. of course this utterly breaks the common non-error-checked pattern "open, write, go out of scope" - which i consider no problem. but i'm just being redundant with my previous posts here. joao didn't try to dispute them any more, so assume they are the ultimate truth. ^^ _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development