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

[Constantin Makshin]

Overriding a public method to make it private doesn't make much sense
because this restriction can be easily circumvented by casting the
pointer/reference to a base class (explicitly or by passing it to a
function, in the context of this thread, expects a QFile or even more
generic QIODevice).
On Aug 24, 2013 2:16 AM, "Alex Malyushytskyy" <alexmalvtk at gmail.com> wrote:

>
> >> 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
>>
>
>
> _______________________________________________
> 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/20130824/920ecb13/attachment.html>