- That's while I love C++ over C - 23 Updates
- A stack container that can pop multiple types - 2 Updates
| Bart <bc@freeuk.com>: Nov 05 11:35PM On 05/11/2021 21:59, Vir Campestris wrote: > If you wrote that code in anything in my company I would downvote the > review. > Any of those versions. Who said I would write it? It's a consequence of a flexible language. The OP was touting the ability to do similar in C++ as making it superior to C. But this is actually very mild compared to most C++ code. If, however, that the need ever come up to do that second example - assigning z to one of a, b, c, d depending on n being 1, 2, 3 or anything else (you can make it zero-based), how would you prefer that written in C++ in a way that doesn't get anyone fired? Assume that any terms could be arbitrarily complex. Assume a, b, c, d are the same type, and z is a compatible type (my implementation requires that). |
| Bart <bc@freeuk.com>: Nov 05 11:46PM On 05/11/2021 23:24, red floyd wrote: > On 11/5/2021 3:25 PM, Lynn McGuire wrote: >> 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. My code fragments, /one of which was the equivalent of a C++ example/, originated in Algol68, usually regarded as elegant. |
| Tony Oliver <guinness.tony@gmail.com>: Nov 05 05:48PM -0700 On Friday, 5 November 2021 at 23:47:14 UTC, Bart wrote: > > [insanely ugly, unreadable, and unmaintainable code fragments redacted] > You're having a laugh I think. > My code fragments, which are [insanely ugly, unreadable, and unmaintainable code fragments] are not welcome in clc++. Take them elsewhere (maybe olcott will enjoy them - he also enjoys posting bollocks in inappropriate newsgroups) |
| Bart <bc@freeuk.com>: Nov 06 01:40AM On 06/11/2021 00:48, Tony Oliver wrote: > which are [insanely ugly, unreadable, and unmaintainable code fragments] > are not welcome in clc++. > Take them elsewhere (maybe olcott will enjoy them - he also enjoys posting bollocks in inappropriate newsgroups) you seem to know about talking bollocks. Nobody here needs to be pretend that your square-bracketed remarks don't mostly aptly describe C++. However maybe I shouldn't have posted snippets of non-topical languages. But it was just a riposte to that gloating (x==y?a:b)=c C++ example. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 06 02:32AM >> My code fragments, > which are [insanely ugly, unreadable, and unmaintainable code fragments] > are not welcome in clc++. I find the "fire them" remarks very odd. Quite apart from the fact that I'd hope everyone enjoys better employment protection than that, what's so bad about conditionally choosing an assignment target compared to conditionally choosing an assigned value? Or is any use of a conditional operator a sacking offence? -- Ben. |
| red floyd <no.spam.here@its.invalid>: Nov 05 08:18PM -0700 On 11/5/2021 7:32 PM, Ben Bacarisse wrote: > so bad about conditionally choosing an assignment target compared to > conditionally choosing an assigned value? Or is any use of a conditional > operator a sacking offence? No, use of the conditional operator is not a sacking offense. Even when used as an lvalue. However, as I said above, I'd insist on training for the person. That is highly unmaintainable code. If I had to use something like that, It would be: int *pInt = (x == y ? &a : &b); *pInt = c; But I'd really prefer if (x == y) a = c; else b = c; You've just inherited some code. Which would you prefer to maintain? |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Nov 06 04:48AM +0100 On 6 Nov 2021 04:18, red floyd wrote: > else > b = c; > You've just inherited some code. Which would you prefer to maintain? It's not a good idea to code C++ for maintenance by people who don't grok the choice operator. Or who would insist on you calling it something else because that's what they've used to. Let the idiots use PHP. - Alf |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 06 12:34AM -0400 On 11/5/21 11:48 PM, Alf P. Steinbach wrote: > On 6 Nov 2021 04:18, red floyd wrote: ... >> No, use of the conditional operator is not a sacking offense. Even when ... > grok the choice operator. > Or who would insist on you calling it something else because that's what > they've used to. Both the C++ and C standards refer to it as the "conditional operator". That is, in fact, the title of section 6.5.15 of the C standard and section 7.6.16 of the C++ standard. Nor is this new terminology - K&R 1st edition used the same terminology. On what grounds do you criticize someone for daring to use precisely the terminology endorsed by the relevant standards and the founders of C itself? According to groups.google.com, there's only ever been four discussions on comp.lang.c++ in which the term "choice operator" was ever used, and you're pretty much the only person using it. The only times other people have used it was in response to messages in which you used the term. There's 81 discussions on comp.lang.c++ where the phrase "conditional operator". |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 05 09:59PM -0700 On 11/5/2021 4:24 PM, red floyd wrote: >> I would fire him. > I was going to say something along the lines of what either you or Vir > said. I might not fire, but I would insist on further training. Indeed! Further training, or make her read the coding rules of the team again. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 05 10:23PM -0700 On 11/5/2021 9:59 PM, Chris M. Thomasson wrote: >> said. I might not fire, but I would insist on further training. > Indeed! Further training, or make her read the coding rules of the team > again. Ohhh, shit. I vaguely remember using the conditional expression ? : in a really nasty macro to avoid an if/else... If I could find that code, you would probably think about firing me! Probably not for the ? :, but for the damn macro internals! Luckily, it was for my on personal use. Yikes! |
| red floyd <no.spam.here@its.invalid>: Nov 05 10:26PM -0700 On 11/5/2021 8:48 PM, Alf P. Steinbach wrote: >> You've just inherited some code. Which would you prefer to maintain? > It's not a good idea to code C++ for maintenance by people who don't > grok the choice operator. I'v got nothing against the conditional operator. My concern is using the result as an lvalue. That's a readability and maintainablility nightmare. |
| red floyd <no.spam.here@its.invalid>: Nov 05 10:27PM -0700 On 11/5/2021 10:23 PM, Chris M. Thomasson wrote: > really nasty macro to avoid an if/else... If I could find that code, you > would probably think about firing me! Probably not for the ? :, but for > the damn macro internals! Luckily, it was for my on personal use. Yikes! As with everything else in C++, there's nothing wrong with the conditional operator ... in the right place. The left hand side of an assignment is NOT the right place. Using the result of a conditional as an rvalue is just fine, I use it all the time. |
| red floyd <no.spam.here@its.invalid>: Nov 05 10:28PM -0700 On 11/5/2021 10:27 PM, red floyd wrote: > conditional operator ... in the right place. The left hand side of > an assignment is NOT the right place. Using the result of a conditional > as an rvalue is just fine, I use it all the time. Another place the conditional is useful is when assigning to a const value or when seating a reference. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 05 10:46PM -0700 On 11/5/2021 10:28 PM, red floyd wrote: >> as an rvalue is just fine, I use it all the time. > Another place the conditional is useful is when assigning to a const > value or when seating a reference. Agreed. For some reason it reminds me of something akin to: _____________ #include <iostream> struct foo { int a; }; int main() { foo a = { 0 }; foo b = { 1 }; { foo const& r = (true) ? a : b; std::cout << &r << "->a = " << r.a << "\n"; } { foo const& r = (false) ? a : b; std::cout << &r << "->a = " << r.a << "\n"; } return 0; } _____________ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Nov 05 10:46PM -0700 > conditional operator ... in the right place. The left hand side of > an assignment is NOT the right place. Using the result of a conditional > as an rvalue is just fine, I use it all the time. Why? Seriously, the C++ standard (unlike the C standard) is clear that a conditional expression can be an lvalue if its second and third operands are both lvalues of the same type (I'm oversimplifying the rules a bit). In other words, the language explicitly allows a conditional expression to be the LHS of an assignment. Why do you object to taking advantage of that feature? I don't think I knew about it before seeing this discussion, but now that I do, the meaning of (x == y ? a : b) = c; seems perfectly clear to me. The alternative: if (x == y) { a = c; } else { b = c; } 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. And creating a pointer variable: auto p = x == y ? &a : &b; *p = c; seems silly when you can just use the conditional operator directly. -- 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 */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Nov 05 10:48PM -0700 > 1st edition used the same terminology. On what grounds do you criticize > someone for daring to use precisely the terminology endorsed by the > relevant standards and the founders of C itself? An irrelevant aside: It's also commonly called the "ternary operator", because it happens to be the only operator in the language that takes three operands. "Conditional operator" is more descriptive. [...] -- 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 */ |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 06 07:33AM +0100 Am 05.11.2021 um 22:59 schrieb Vir Campestris: >> It's not a big enough reason to switch. > If you wrote that code in anything in my company I would downvote the > review. That's just a matter of habits and taste. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 06 07:36AM +0100 Am 06.11.2021 um 04:18 schrieb red floyd: > a = c; > else > b = c; It seems more readable to you because the ?:-variant is not common. If this would be a common style you would consider this also as readable. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 06 07:37AM +0100 Am 06.11.2021 um 06:26 schrieb red floyd: > I'v got nothing against the conditional operator. My concern is using > the result as an lvalue. That's a readability and maintainablility > nightmare. Absolutely not. |
| Ike Naar <ike@sdf.org>: Nov 06 06:59AM > else > b = c; > You've just inherited some code. Which would you prefer to maintain? A maintenance issue here is that c is written twice. Here c is a simple variable, but it could be a more complex expression. If c changes during maintenance, the change has to be applied twice. |
| David Brown <david.brown@hesbynett.no>: Nov 06 10:58AM +0100 On 06/11/2021 00:46, Bart wrote: > You're having a laugh I think. > My code fragments, /one of which was the equivalent of a C++ example/, > originated in Algol68, usually regarded as elegant. We are no longer living in 1968. Even if these things were regarded as "elegant" at that time (and I doubt it), that does not make them appropriate today. (The /language/ Algol68 was considered elegant at 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. I've seen code snippets and suggestions posted here by folks like Ben, James and Keith that would immediately be downvoted in a review for my kind of work - and I would expect they 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. |
| David Brown <david.brown@hesbynett.no>: Nov 06 11:12AM +0100 On 06/11/2021 04:18, red floyd wrote: > else > b = c; > You've just inherited some code. Which would you prefer to maintain? The version that includes brackets: if (x == y) { a = c; } else { b = c; } There are times when a more compact representation is helpful in the clarity and maintainability of the code, so it is hard to be too categorical. But if you need to re-read an expression several times to figure out what it means, you are putting too much into too small a space. Spread it out, and it's a lot clearer. (And it also gives space to add comments saying /why/ your code is making these various assignments.) There is a bit of a self-fulfilling prophecy with techniques like having a conditional in an lvalue. People don't expect it in code, making it easy to misunderstand or overlook. Code techniques that are easily misinterpreted should be avoided, thus making such code rare and unexpected. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 06 11:08AM > else > b = c; > You've just inherited some code. Which would you prefer to maintain? The shorter and clearer (x == y ? a : b) = c; 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. -- Ben. |
| Tony Oliver <guinness.tony@gmail.com>: Nov 05 05:38PM -0700 On Friday, 5 November 2021 at 19:48:15 UTC, Bonita Montero wrote: > no maximum storage requirement of the items, whereas variant > 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. |
| red floyd <no.spam.here@its.invalid>: Nov 05 08:19PM -0700 On 11/5/2021 5:38 PM, Tony Oliver wrote: >> 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. In Bonita's defense, "sth" = "something". I've seen that usage elsewhere. |
| 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