I agree that explicit object deinitialization (closing files, freeing memory, etc.) in the callee is a bad thing (implicit through destructors or object's management of its [internal] data is OK IMHO). bar() was just a hypothetical example with the idea "rely on the [expected] behavior of the declared type, not specifics of the actual one".
On 08/28/2013 05:51 AM, Thiago Macieira wrote:
> On terça-feira, 27 de agosto de 2013 16:55:44, Alex Malyushytskyy wrote:
>> QIODevice::close() - closes the device
>>
>> when
>>
>> 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).
>
> QTemporaryFile::close() calls QIODevice::close(), so it does what any
> QIODevice is expected to do.
>
>> According to above, example below does not make sense
>> cause you can't delete file after call to bar(). .
>> Relying on interface is already broken.
>>
>>> void bar (QIODevice& zzz)
>>> {
>>>
>>> // ...
>>> zzz.close(); // Oops
>>> }
>
> You couldn't delete in bar() anyway because you don't know if this is a file
> or
> not. It could be a QProcess.
>
> Now, assuming you have a QFile above instead of QIODevice, you still can't be
> assured that you can delete, because:
>
> a) the directory could not be writable by you
> b) the file could be locked by another process
> c) the file is in a read-only filesystem, including virtual filesystems
> (e.g.,
> the resources filesystem)
>
> The way I see it, you have a problem in your design. So I will agree with you
> when you say "example below does not make sense". It doesn't. It's not a good
> design.
>
> Since QTemporaryFile auto-deletes, you shouldn't call a function that tries
> to
> delete it. You should only call that function if you know you opened a QFile
> and that it should be deleted.
>
>> The whole problem is that QTemporaryFile::close() does not do what it is
>> supposed to do.
>
> I disagree. It does exactly what it's supposed to do.
>
> You meant to say: "QTemporaryFile::close() does not do what I expected it to
> do"
>
> Note: QTemporaryFile::close() is QFile::close(). The difference is in the
> file
> engine.
>
>> And I see only 2 ways to fix it:
>>
>> 1. Change the interface so user can't call function which is source of the
>> problem.
>> 2. Change implementation so close works as expected.
>
> Since I disagree that it is a problem to begin with, I disagree that there
> needs to be a "fix". So for me, we have option 3: do nothing.
>
>>>> The only way to make it work would be for close() to unset the fileName()
>>
>> again. When open() is called again, it creates a new file name based on the
>> template.
>
> That would be fine.
>
> Except that people expect fileName() to return something non-empty after
> close().
>
>>>> Which is exactly what you don't want.
>>
>> I might be missing something , but I would can't see why not.
>>
>> If you say that lifetime of the temporary file (including name) is limited
>> by opening and closing
>> I do not see any security issues.
>> It is also what I would expect temporary file to do by default.
>
> To be honest, it's what I would have preferred.
>
> However, people expect to have access to the file name after close().
> Therefore, we can't release (delete) the file at close() time.
>
> Anyway, this behaviour is now too ingrained in Qt. It's unlikely to ever
> change.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
