Just for information, I'm not picking on Qt's source code, they're doing phenomenal job, just because i had that code in front of me when i was writing the email.But let me keep using it.Like i said, QIODevice is a base class of many derived classes, QFile, QAbstrackSocket...etcMost of these classes rely on the model that there are two buffers, one for reading the other for writing. So they do some, pointers book keeping and dumps the amount of bytes you ask for, or the whole remaining unread buffer content depending on what method yoy call.The catch here is that the source from where the read buffer for example is filled, is just one source feed.But for the case of QProcess there are 2 sources feed, stdErr and stdOut.The general readAll method won't give you the same model you used too in the other derived class, because if you call readAll a question raises, are you looking at StdErr or StdOut or a mixture and in which order?Obviously you need to give the end user a way to introspect that, which Qt did, by providing two methods readAllStandardError, readAllStandardOutput (observed the shifting from general case covered by the base class to a specific case for this specific derived class)The existence of readAll, and the way you used to use it in other derived class is still there, but lost its meaning, why?Because as soon as you instantiate QProcess a default source feed is picked for you ( is like you say in plain English: ok i will pick a filter for you, so next time you call readAll, i will give back only that buffer flitered)So for example, if the default is StdOut, but the instance got feed from StdErr, calling readAll won't return a thing (i tried it many times).The mental model of receiving everything is there, from the repetitive usage of that method in other dervied classes, but the current usage is different. Pavlov reflexes kinda of situation here.Flagging that shifting would make much sense to the users.Again, I'm not picking on Qt, but you can use this explanation to imaging a more general case.But the question here is the following:Why are we reluctant to communicate more information?Isn't the standard or the compiler a way to navigate a language design easily?Why should we oppose a need, no matter how ephemeral, for the time being, it looks?Also, with such a feature, you could unlock a new way of designing classes, not thought before. Maybe the only wrong move in all this discussion, is that i came rushing here excited to share what i thought could benefit the community, next time i will keep things for me, until i become filthy rich using them , then maybe, i will consider sharing them, ;)(Just kidding)NadSent from my Galaxy
-------- Original message --------From: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Date: 3/22/22 6:13 AM (GMT+04:00) To: std-proposals_at_[hidden] Cc: Jason McKesson <jmckesson_at_[hidden]> Subject: Re: [std-proposals] Detect non overriden function On Mon, Mar 21, 2022 at 1:26 PM organicoman via Std-Proposals<std-proposals_at_[hidden]> wrote:>> 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,When you started the conversation, you thought this function was`virtual`. You do understand that this makes it difficult for us tobelieve you when you say that you understand the class, yes?> If QProcess receives writes on its standrdError channel, and you set your channel to be standardOutput, calling readAll won't return a thing.How do you know that this is not precisely the behavior the userwants? Why should a user, who is using the class's interfacecorrectly, get a warning for it?> 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.So now it's no longer about the relationships of base and derivedclass interfaces. It seems your core problem is *name* of thisparticular function. That if the base class function had been called`readAllFromDefault`, you wouldn't have a problem with it.To the extent that `readAll` is not the best name, this is purely anaming convention problem. You don't solve naming problems withlanguage features or even static analysis tools. You solve it bypicking a better API.> (I picked up QProcess::readAll, for lack examples, i didn't suspect it was not virtual, which is another reason to be notified)But it isn't a reason to be notified. A derived class is a base class;that's what it *means* to be a derived class. The base class interfaceis, and of a right ought to be, considered 100% as valid as thederived class's interface. And in QProcess, this is the case, as faras the intent of the developers is concerned.> 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.But we've already established that "the implementer" in this case (ie:Qt's developers) *wants* the API this way. This wasn't designed byaccident. They intend and expect users to use the base class interfaceeven when they knowingly use the derived class.That is, if the developers had the ability to issue warnings if youused `readAll` from the derived class, they *would not* use thatability. So even if what you wanted was available, it wouldn't solvethis "problem" because the developers simply do not agree that it is a"problem".-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals