So you want the compiler to emit a warning that you're calling a method that
was not overriden and was not meant to be overridden?
No.
Are you sure you
understand the documentation of the class you're trying to use in the first
place?
Yes,
If QProcess receives writes on its standrdError channel, and you set your channel to be standardOutput, calling readAll won't return a thing.
That's why, i guess, they added two methods:
readAllStandardError
readAllStandardOutput
Which both stores the current write channel switch to the appropriate channel then call readAll, then restore back the old channel.
And since as an end user, I'm allowed to call readAll, which is available thru the base class,
From its name, it sounds that it reads anything available no matter what channel you are on. Which obviously does not.
(I picked up QProcess::readAll, for lack examples, i didn't suspect it was not virtual, which is another reason to be notified)
There are other virtual functions in the class that derived classes often
override but don't have to, like seek() or bytesAvailable(). It's often wrong
to use the base implementation in a derived class.
Base class implementation should fit the largest use cases, you derive only to implement specific singular cases, or to devide the generalities into relatively smaller groups. Otherwise you will have a jungle of derived classes.
Thus, i guess, it is good to know, when you call what.
But here's the thing: the derived class's implementer makes that choice, not
you as a user. There's no reason for you to get a warning, if the class
implementer has done their job properly. If you think that they haven't and
that there's a bug, that's a different story, but then there s little the
standard and the compilers can help with.
No, it can help.
Help the implementer communicate his intentions using warnings, annotations, attributes, to expose his design to the users, get feedback, refine the implementation.
No one can guess all the scenarios of usage of his library.
Except for the -fkeep-programmers-inline option we've been asking of GCC for
some time. Please make a proposal for that one and post next Friday.
Or maybe, -fchange-your-profession, lol
Because staying inline won't create new ideas.
Nad
-------- Original message --------
From: Thiago Macieira <thiago@macieira.org>
Date: 3/21/22 5:53 PM (GMT+04:00)
To: std-proposals@lists.isocpp.org, organicoman <organicoman@yahoo.fr>
Subject: Re: [std-proposals] Detect non overriden function
> "Because readAll is not virtual."
>
> 😱, that's true. It's not!!!!
> Wow, that's definitely another reason to flag it.
So you want the compiler to emit a warning that you're calling a method that
was not overriden and was not meant to be overridden? Are you sure you
understand the documentation of the class you're trying to use in the first
place?
read readLine and readAll are all front-end, non-virtual functions that call
the back-end virtual readBlock function. That one is a pure virtual, so every
single class deriving from QIODevice must provide its own implementation.
There are other virtual functions in the class that derived classes often
override but don't have to, like seek() or bytesAvailable(). It's often wrong
to use the base implementation in a derived class.
But here's the thing: the derived class's implementer makes that choice, not
you as a user. There's no reason for you to get a warning, if the class
implementer has done their job properly. If you think that they haven't and
that there's a bug, that's a different story, but then there s little the
standard and the compilers can help with.
Except for the -fkeep-programmers-inline option we've been asking of GCC for
some time. Please make a proposal for that one and post next Friday.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel DPG Cloud Engineering