[Interest] Strange undeletable QTemporaryFile. Is it a bug?

[Alex Malyushytskyy]

>> I can't say that I am very happy with a non-closing close() and a lying
isOpen(). Even if documented, it goes against any expectations.

I disagree, then You would have
QTemporaryFile  attached to file which is not anymore
under control.
This would be even more confusing and made documented features wrong:
"the file will subsequently be removed upon destruction of the
QTemporaryFile object."

"Detaching" could be made in close(), but in this case you leave useless
now QTemporaryFile alive.
I think current implementation is less alone prone.
What can be done - I would override close just to make it private, so
people do not call it.

Regards,
    Alex



On Fri, Aug 23, 2013 at 11:50 AM, Guido Seifert <wargand at gmx.de> wrote:

>
> > open() means it succeeded in opening.
> >
> > QTemporaryFile::close() truncates and repositions, but doesn't *close*
> the
> > file. If you really want to close, destroy the object or force it to
> open a new
> > file (with a new name).
>
> Bah, stupid me. Wrong function. I meant of course 'isOpen()', sorry. Am I
> so wrong that I expect a 'true' when the file is still open?
>
> But, erm... yes... now that you say it, I can even find this behaviour in
> the docs:
>
> Reopening a QTemporaryFile after calling close() is safe. For as long as
> the QTemporaryFile object itself is not destroyed, the unique temporary
> file will exist and be kept open internally by QTemporaryFile.
>
> I can't say that I am very happy with a non-closing close() and a lying
> isOpen(). Even if documented, it goes against any expectations.
>
> Guido
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130823/4eb9f0ab/attachment.html>