On Friday 06 January 2012 17:11:29 Thiago Macieira wrote: > On Friday, 6 de January de 2012 18.34.21, David Faure wrote: > > On Thursday 05 January 2012 22:38:37 Thiago Macieira wrote: > > > What happens if you open the file in read or read-write mode while the > > > flag > > > is on? > > > > I think that should just ignore the request for a temp file, since it > > cannot possibly be honoured. > > > > Or if you prefer it could print a warning and fail. > > The first solution doesn't look nice. It would have to fail opening > completely.
Well, this is just like using ReadOnly | Truncate, for instance. These are incompatible. What happens? Truncate will be ignored, and you don't even get a warning. (Both the code and a quick test indicate this). I don't really mind, it just seems inconsistent. > But I think I prefer a QSaveFile, derived from QFile, with the proper > semantics. Heh, a 4th solution, to make this debate even more endless :-) Why would this be better? It can't be "because it's not clear which file some methods should work on" (Joao's argument), since it would still have all the QFile methods. It can't be because we need additional API compared to QFile, or is it, for one single rollback method? ;) It could even add an unnecessary need for casting, I could imagine: a public method takes a QFile, then you realize it should handle disk-full situations better, so you pass it a QSaveFile and you have to downcast it internally to call rollback in case of a truncated write...). This doesn't sound appealing. A QFile builtin feature makes this much nicer. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development