[Interest] Strange undeletable QTemporaryFile. Is it a bug?
cmakshin at gmail.com
Sun Aug 25 13:02:16 CEST 2013
void bar (QIODevice& zzz)
zzz.close(); // Oops
void foo ()
The function bar() may be replaced by anything that doesn't care what type
I/O object to work with (e.g. QDataStream). "Why the hell does a function
close an object owned by something else?" is another question, but the idea
as a whole is simple and obvious -- if a function works with a base class
(e.g. anything that can act as an I/O device, be it an actual file, memory
buffer, etc.), the hint "don't call this method because in one of derived
classes it does not what the name implies" doesn't work.
On Aug 24, 2013 2:05 PM, "Till Oliver Knoll" <till.oliver.knoll at gmail.com>
> Am 24.08.2013 um 09:46 schrieb Constantin Makshin <cmakshin at gmail.com>:
> 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).
> Casting? Pointers? Why so complicated?
> C++ makes this easy for you:
> #define private public
> #include "Foo.h"
> There you go: all private members of class Foo have just become public! A
> hip hip horray for the preprocessor ;)
> Oh, by the way: should you feel the urge to pass on this "tip" to someone
> else: please don't mention my name, will you? ;)
> But on a more serious note: overriding a public method and make it private
> is more like a "design decision" and a strong hint to the caller not to
> call this member on that concrete class instance anymore: why not? Go read
> the docs! (And if you still feel like calling it: C++ offers you plenty of
> choices ;))
> Interest mailing list
> Interest at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Interest