So you want the compiler to emit a warning that you're calling a method thatwas 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 readAllStandardOutputWhich 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, lolBecause staying inline won't create new ideas.NadSent from my Galaxy
-------- Original message --------From: Thiago Macieira <thiago_at_[hidden]> Date: 3/21/22 5:53 PM (GMT+04:00) To: std-proposals_at_[hidden], organicoman <organicoman_at_[hidden]> Subject: Re: [std-proposals] Detect non overriden function On Monday, 21 March 2022 03:48:56 -03 organicoman wrote:> "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