On Fri, May 31, 2024 at 09:14:21AM +0100, Richard Sandiford wrote: > Segher Boessenkool <seg...@kernel.crashing.org> writes: > > Hi! > > > > On Fri, May 31, 2024 at 01:21:44AM +0530, Ajit Agarwal wrote: > >> Code is implemented with pure virtual functions to interface with target > >> code. > > > > It's not a pure function. A pure function -- by definition -- has no > > side effects. These things have side effects. > > > > What you mean is this is *an implementation* for C++ functions without > > a generic implementation. An obfuscation some people (like me) would > > say. But please call things what they are! So not "pure function". > > That has a meaning, and this isn't it. > > "pure virtual function" is an established term. The "pure" modifies > "virtual", not "function". > > The description is correct because the patch adds pure virtual functions > to the base class and expects the derived class to override and implement > them.
But this code -- the architecture implementation! -- certainly does *not* add abstract functions: it should provide an implementation for them, instead. So the commit message is completely misleading :-( And no, it is not an established term, not outside of the C++ world. Which GCC agreed *not* to dive too much into. You can only sanely write most of compilers -- just like anything where algorithmics matter -- in an imperative, procedural language. Obfuscation (like action at a distance like this, where the meaning of a program depends hugely on knowledge of other parts of the program, far away!) is the devil. Reading the program is at least 1000x more important than writing it. Writing is easy. Reading and understanding, not so much. > >> * config/aarch64/aarch64-ldp-fusion.cc: Add target specific > >> implementation of additional virtual functions added in pair_fusion > >> struct. > > > > This does not belong in this patch. Do not send "rs6000" patches that > > touch anything outside of config/rs6000/ and similar, certainly not in > > config/something-else/! > > > > This would be WAY easier to review (read: AT ALL POSSIBLE) if you > > included some detailed rationale and design document. > > Please don't shout. > > I don't think this kind of aggressive review is helpful to the project. And I don't think wasting people's time is helpful. I don't shout. If you read that as shouting, that's not my problem. It is EMPHASIS (there are no small caps in email). Do you prefer *fat print* for that? Or /slanted/? Or **italics**? _Underlined_ perhaps? Segher
