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

Constantin Makshin cmakshin at gmail.com
Tue Aug 27 05:57:24 CEST 2013

The bar() function from that example may be part of a library that
neither wants nor needs to know anything about specifics of the actual
type of 'zzz'. Actually, isn't "rely on the interface, not
implementation" the primary idea of inheritance?

On 08/27/2013 02:36 AM, Alex Malyushytskyy wrote:
> Making function which were public in the parent, private in the child
> shows that function should not be called.
> That is it.  And that is the case.
> It does not make it impossible to shoot yourself at the feet (whatever
> way you choose)  and access it.
> You can do everything in C++.
> But if you do it, it is your problem and responsibility and you do not
> feel frustrated cause the behavior does not meet your expectations.
> QTemporaryFile::close () is not meant to be public. User have no use of
> it. Make it private and this question will not ever rise again.
> On Sun, Aug 25, 2013 at 4:02 AM, Constantin Makshin <cmakshin at gmail.com
> <mailto:cmakshin at gmail.com>> wrote:
>     void bar (QIODevice& zzz)
>     {
>         // ...
>         zzz.close(); // Oops
>     }
>     void foo ()
>     {
>         QTemporaryFile file;
>         bar(file);
>     }
>     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 <mailto:till.oliver.knoll at gmail.com>>
>     wrote:
>         Am 24.08.2013 um 09:46 schrieb Constantin Makshin
>         <cmakshin at gmail.com <mailto: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 ;))
>         Cheers,
>           Oliver

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130827/2a3332fa/attachment.sig>

More information about the Interest mailing list