- That's while I love C++ over C - 15 Updates
- A stack container that can pop multiple types - 1 Update
| David Brown <david.brown@hesbynett.no>: Nov 06 12:25PM +0100 On 06/11/2021 06:46, Keith Thompson wrote: > is more verbose and could be problematic if c is a complicated > expression; the risk is that a later maintainer might modify one > instance of c and not the other. That is a poor argument, IMHO, as it is so easily solved : auto new_c = complicated_expression; if (x == y) { a = new_c; } else { b = new_c; } Verbose is often good - though certainly not /always/ good. The important things are the clarity of the code and the /appropriate/ maintainability (if it is extremely unlikely that "c" will ever be changed, then it is inappropriate to place emphasis on making it easy to change). It should be easy to see what code does, easy to write correctly, hard to write incorrectly, and easy to spot when it is incorrect. It is always difficult to judge the clarity of a simple example code snippet, because it misses the context. You wonder what would happen if "c" were more complicated - what if "a" and "b" were more complicated? They are only written once, so only need to be changed once, but a complicated expression there would make the conditional operator version hard to read and easy to misunderstand. What if the logic behind the code - the reasons for doing the operations, rather than the operations themselves - were complicated and needed commenting? The expanded version gives plenty of places to add comments, unlike the conditional operator version. What if /you/ are the smartest programmer in your team, and others who have to understand it are relatively new to C++ ? In a perfect world, any development team would only consist of people who were familiar with all the intricacies of the language. We don't live in a perfect world, and the reality is that the code we write will sometimes have to be understood by or maintained by people with very different levels of experience and knowledge. Where you draw the line between "this is something we expect everyone to understand" and "this is advanced stuff you might not have seen before" is going to vary enormously - I am not at all suggesting conditional operators in lvalues are too obscure to use in general C++ code. But they /are/ too obscure for /some/ projects and coding styles. "Always write code as though the person who will maintain it is a violent psychopath who knows where you live" (I've forgotten the source of that quotation). Also assume they are not as clever or experienced as you are. |
| Bart <bc@freeuk.com>: Nov 06 11:44AM On 06/11/2021 03:18, red floyd wrote: > If I had to use something like that, It would be: > int *pInt = (x == y ? &a : &b); > *pInt = c; So you've added a pointer variable, an extra line, two & operators, a dereference * operator, and an extra assignment. You've also assumed a type of 'int' (I guess you'd change that to 'typeof' to avoid even more maintenance). Your solution is on two separate lines; somebody could add something in between that changes pInt and/or c. But also, the orginal pattern has disappeared. > else > b = c; > You've just inherited some code. Which would you prefer to maintain? Assume c can be arbitrarily complex: (1) You now have to ensure the two 'c' expressions are actually identical (2) If c needs to change, then you need to maintain both (3) There could be more than two 'c' expressions (4) Anyone reading the code would need to analyse all the RHS expressions to see the pattern, namely that it's assigning the same RHS value to one of multiple LHSs. Here's an example of ?: used for something that is between an lvalue and rvalue: void fred(int &a) { a = 777; } int main(void) { int a=100, b=200; int c=0; fred((c ? a : b)); } This selects one of two variables to pass as a reference parameter. Imagine there are many more parameters (maybe involving more ?: expressions). But I agree with your general point; I wouldn't like to maintain (or try and understand) too-clever code either. I just don't consider ?: used with lvalues to be that clever. |
| Bart <bc@freeuk.com>: Nov 06 12:00PM On 06/11/2021 09:58, David Brown wrote: > the time - that doesn't mean that any code written in it was elegant.) > There are also widely different opinions on these kinds of things, and > widely different needs. But calling it 'insanely ugly' and 'unreadable' is extreme, and was rich coming from a C++ programmer. I found Algol68 highly inspiring and refreshing 40 years ago, but I'd only seen it beautifully typeset in textbooks. The reality is somewhat different, since that language made a rod for its own back by allowing spaces within identifiers. That meant requiring various schemes to distinguish reserved words from identifiers, such as using all-caps for the former. The result looks dreadful. However the fragments I posted didn't include those elements; they were perfectly clean examples of syntax. > would have a similar reaction to some things /I/ write. It doesn't mean > code is necessarily objectively bad, merely that it is not appropriate > for the requirements of that kind of coding. Downvoted; fired; retraining... The latter sounds like something from /1984/ or /A Clockwork Orange/. Not liking code is fair enough, but to expound on what you would do to someone who wrote that code? What is the matter with people here? (And I don't even write code like that! I checked my [static] codebase for examples of conditional or multiple LHSs in an assignment, and I couldn't find any. I just implement the feature.) |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 06 01:18PM >> *pInt = c; > So you've added a pointer variable, an extra line, two & operators, a > dereference * operator, and an extra assignment. Technically, an extra initialisation. There's still just one assignment. > You've also assumed a type of 'int' (I guess you'd change that to > 'typeof' to avoid even more maintenance). This is C++, so you'd use auto (though that may also be forbidden -- I can't begin to guess the rules). Also, you'd use a reference (if permitted): auto &var = x == y ? a : b; var = c; but I can't see how that helps at all. -- Ben. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 06 03:03PM +0100 Am 06.11.2021 um 12:08 schrieb Ben Bacarisse: > I can see at a glance that the same thing is always assigned (no need to > check two places though when it's just 'c' that's not hard), and I can > see instantly that what is determined by the test is the destination. Right, I also think that this is the best solution. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 06 07:04AM -0700 On Saturday, 6 November 2021 at 14:00:51 UTC+2, Bart wrote: > /1984/ or /A Clockwork Orange/. > Not liking code is fair enough, but to expound on what you would do to > someone who wrote that code? What is the matter with people here? Don't take it personally. When people are grumpy then they are and usenet is not good place for discussing the reasons. |
| scott@slp53.sl.home (Scott Lurndal): Nov 06 02:43PM >>> On 11/5/2021 4:59 PM, Vir Campestris wrote: >> [insanely ugly, unreadable, and unmaintainable code fragments redacted] >You're having a laugh I think. I doubt it. I'd reject any such C or C++ code in a review as well. It not only must work, but it must be maintainable in the future. >My code fragments, /one of which was the equivalent of a C++ example/, >originated in Algol68, usually regarded as elegant. Here is a news flash. C is not Algol68. And as a former Burroughs employee, I would never have called Algol68 elegent. |
| David Brown <david.brown@hesbynett.no>: Nov 06 03:50PM +0100 On 06/11/2021 13:00, Bart wrote: >> widely different needs. > But calling it 'insanely ugly' and 'unreadable' is extreme, and was rich > coming from a C++ programmer. I agree it is extreme - just as your continual characterisations of C++ programming are extreme. Don't expect the slightest sympathy when you have come to a newsgroup for C++ users and fans and spend most of your time telling them how terrible you think the language is. > /1984/ or /A Clockwork Orange/. > Not liking code is fair enough, but to expound on what you would do to > someone who wrote that code? What is the matter with people here? I have made no comment about what I would do to or with someone who wrote any of the code in question. I merely said that I would be likely to put a black mark against it in a code review - and even that is dependent on the circumstances. Fortunately, I think most people who claim "I'd fire someone for doing that" are not in a position to fire anyone. > (And I don't even write code like that! I checked my [static] codebase > for examples of conditional or multiple LHSs in an assignment, and I > couldn't find any. I just implement the feature.) Sure. You did not even suggest that it was a good way to write code - merely a possible way to do so. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 06 05:13PM > And as a former Burroughs employee, I would never have called Algol68 > elegent. I'm curious as to why. Yes, I know the history, but why was "being there" such a factor in your assessment? -- Ben. |
| Manfred <noname@add.invalid>: Nov 06 07:12PM +0100 On 11/6/2021 12:08 PM, Ben Bacarisse wrote: > I can see at a glance that the same thing is always assigned (no need to > check two places though when it's just 'c' that's not hard), and I can > see instantly that what is determined by the test is the destination. Beauty is in the eye of the beholder. I guess you like puzzles, so to your eyes this is quite clear, while others not as familiar with this construct harshly label it as unmaintainable. FWIW, to me the construct looks just a bit spicy, which is still good. Expecially since the "odd" part is having the ternary on the LHS, but even for those for which it is not immediate to grok, it still can't be misinterpreted(*), so for me it's a pass too. (* I mean, if a reader would have to struggle figuring out what is the destination between a/b or x/y, they'd have a much bigger problem than the writer) |
| Bart <bc@freeuk.com>: Nov 06 06:57PM On 06/11/2021 18:12, Manfred wrote: > Beauty is in the eye of the beholder. I guess you like puzzles, so to > your eyes this is quite clear, while others not as familiar with this > construct harshly label it as unmaintainable. Are you saying that: c = (x == y ? a : b); is perfectly clear, while: (x == y ? a : b) = c; is a total mystery? /That/ would be a puzzle to me! What about: (x == y ? a : b) + c; c + (x == y ? a : b); A[x==y ? i : j] = c: The last assigns to either A[i] or A[j], instead of either a or b. |
| scott@slp53.sl.home (Scott Lurndal): Nov 06 08:16PM >> elegent. >I'm curious as to why. Yes, I know the history, but why was "being >there" such a factor in your assessment? Had to use it. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 06 08:25PM >>I'm curious as to why. Yes, I know the history, but why was "being >>there" such a factor in your assessment? > Had to use it. Ah! It would have been clearer if you'd said that more directly. I had the opposite reaction to using it, but I suppose that's to be expected. -- Ben. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Nov 06 01:27PM -0700 > On 06/11/2021 06:46, Keith Thompson wrote: >> red floyd <no.spam.here@its.invalid> writes: [...] > } else { > b = new_c; > } To be clear, I respect your opinion. I just don't share it in this case. I don't see your replacement code as a "solution", because I don't see the shorter version as a problem. Expanding one line to six can make sense in some cases. I just don't see this as one of those cases. In my humble opinion, the biggest barrier to understanding (x == y ? a : b) = c; is knowing that a conditional expression can appear on the LHS of an assignment, i.e., that it can be an lvalue. Any C or C++ programmer should already understand that the LHS of an assignment is an expression that's evaluated to determine what object is to be assigned to. Once you realize that a conditional expression can be an lvalue, the meaning **IMHO** becomes obvious. Of course in real code you very probably wouldn't call the variables x, y, a, b, and c. With meaningful names, I suspect the intent of the code would be clearer. If I saw that line presented as C, my reaction would be that it's illegal, but *if it were legal* the meaning would be obvious. [...] > violent psychopath who knows where you live" (I've forgotten the source > of that quotation). Also assume they are not as clever or experienced > as you are. Apparently it originated in a post by John F. Woods, right here on comp.lang.c++ in 1991. https://groups.google.com/g/comp.lang.c++/c/rYCO5yn4lXw/m/oITtSkZOtoUJ?pli=1 I've always liked that quotation. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 06 08:50PM > Beauty is in the eye of the beholder. I guess you like puzzles, so to > your eyes this is quite clear, while others not as familiar with this > construct harshly label it as unmaintainable. Personally, I am not concerned with beauty, and I hate puzzles! I like the simple version because it is clear and explicit. Yes, those unfamiliar with it may not like it or find it in some way puzzling. But rather than re-train the programmer who writes the clear but uncommon code above, why not re-train the maintenance programmers to (a) not touch any line of code they don't fully understand, and (b) know how to find out about the language they are working in. And, remember, this is C++ we are talking about. Using a conditional expression as an lvalue must be one of easiest parts the language to grasp, even when never seem before! > (* I mean, if a reader would have to struggle figuring out what is the > destinaion between a/b or x/y, they'd have a much bigger problem than > the writer) Agreed. Also, I think prompting a few "oh, I see" moments in the mythical lowest common denominator maintenance programmer is no bad thing. -- Ben. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 06 04:25PM +0100 Am 06.11.2021 um 01:38 schrieb Tony Oliver: >> is internally usually sth. like a union and a type tag, which >> might consume more memory, but is significantly faster. > I assume you're talking about std::variant. It is not internally using south, whatever you think. std:: can be omitted. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment