That's while I love C++ over C

[Bonita Montero]

(x == y ? a : b) = c;

[Bart]

On 03/11/2021 19:39, Bonita Montero wrote:

> (x == y ? a : b) = c;

Hey, I can do that:

(x = y | a | b) := z

and also:

(n | a, b, c | d) := z

(Assign to one of n lvalues.) Or even:

if x then a elsif y then b else c fi := z

Lots of such things in an expression-based language. But this is in a
language not much higher than C in level; it doesn't require the vast
complexity of C++.

If C doesn't support this, that's a deliberate choice. It means someone
having to instead write:

*(x == y ? &a : &b) = c;

It's not a big enough reason to switch.

[Vir Campestris]

If you wrote that code in anything in my company I would downvote the
review.

Any of those versions.

Andy

[Lynn McGuire]

I would fire him.

Lynn

[red floyd]

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]

>>
>> If you wrote that code in anything in my company I would downvote the
>> review.
>>
>> Any of those versions.

> 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.

[Bart]

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]

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]

On Friday, 5 November 2021 at 23:47:14 UTC, Bart wrote:
> 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,

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]

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]

Tony Oliver <guinne...@gmail.com> writes:

> On Friday, 5 November 2021 at 23:47:14 UTC, Bart wrote:
>> 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,
>
> 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, 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]

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]

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

...

> 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.

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]

Indeed! Further training, or make her read the coding rules of the team
again.

[Chris M. Thomasson]

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]

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]

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]

Another place the conditional is useful is when assigning to a const
value or when seating a reference.

[Chris M. Thomasson]

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]

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.T...@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[Keith Thompson]

James Kuyper <james...@alumni.caltech.edu> writes:
> 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
> ...
>> 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.
>
> 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?

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.

[...]

[Bonita Montero]

That's just a matter of habits and taste.

[Bonita Montero]

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]

Absolutely not.

[Ike Naar]

On 2021-11-06, red floyd <no.spa...@its.invalid> wrote:
> 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?

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]

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]

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]

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.

[David Brown]

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]

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.

> 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?

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]

On 06/11/2021 09:58, David Brown wrote:
> On 06/11/2021 00:46, Bart wrote:
>> 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.
>
> 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.

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.

> 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.
>

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]

Bart <b...@freeuk.com> writes:

> On 06/11/2021 03:18, red floyd wrote:
>> On 11/5/2021 7:32 PM, Ben Bacarisse wrote:
>
>> 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;
>
> 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]

Am 06.11.2021 um 12:08 schrieb Ben Bacarisse:

> 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.

Right, I also think that this is the best solution.

[Öö Tiib]

On Saturday, 6 November 2021 at 14:00:51 UTC+2, Bart wrote:
>
> 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?

Don't take it personally. When people are grumpy then they are and
usenet is not good place for discussing the reasons.

[Scott Lurndal]

Bart <b...@freeuk.com> writes:
>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.

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]

On 06/11/2021 13:00, Bart wrote:
> On 06/11/2021 09:58, David Brown wrote:
>> On 06/11/2021 00:46, Bart wrote:
>>> 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.
>>
>> 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.
>
> 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.

>
> 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.
>
>> 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.
>>
>
> 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?

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]

sc...@slp53.sl.home (Scott Lurndal) writes:

> 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]

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]

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 Lurndal]

Had to use it.

[Ben Bacarisse]

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]

David Brown <david...@hesbynett.no> writes:
> On 06/11/2021 06:46, Keith Thompson wrote:
>> red floyd <no.spa...@its.invalid> writes:

[...]

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.

[...]

> "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.

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.

[Ben Bacarisse]

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!

> 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

> (* 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.

[Manfred]

On 11/6/2021 9:27 PM, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
[...]

>
> 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.

More precisely, the C++ standard says the "target type" of the operator
is (simplifying) "If E2 is an lvalue, the target type is “lvalue
reference to T2”" , the point being it's a reference.

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.
>

The problem in C is not that it's illegal per se. It can't work because
C does not have references, which makes it somewhat hard to guess what
the construct would mean.
(unless by *if it were legal* you mean if C had references, but that's
quite wider a scope than the conditional itself)

It's obvious with function return values:

/* C++ */
int& foo()
{
static int n = 0;
return n;
}

foo() = 42; // OK

/* C */
int bar()
{
static int n = 0;
return n;
}

bar() = 42; /* ?!? error: lvalue required as left operand of assignment */

[Ben Bacarisse]

Manfred <non...@add.invalid> writes:

> On 11/6/2021 9:27 PM, Keith Thompson wrote:

<snip>

>> 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.
>
> The problem in C is not that it's illegal per se. It can't work
> because C does not have references, which makes it somewhat hard to
> guess what the construct would mean.

You don't need references for it to work, or even make sense, in C. In
C, the LHS of an assignment must be an lvalue expression of which there
are many (for example a[42] and *p). If the standard declared
conditional expressions to be lvalues, the construct would be legal.

<snip>
--
Ben.

[David Brown]

Fair enough. And discussing different opinions like this is a good way
to learn - whether we learn new ideas, or learn more about how other
people might see things, or learn something about ourselves when we are
pushed into thinking about our own opinions.

>
> 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.

I have a preference towards spacing things out rather than having a
compact representation. That's a preference, not an absolute - there
can be many overriding factors, and the "best" choice at any given time
can vary significantly. (I think we can ignore the choice of brace
style for now - that's a different matter.)

Some of the reasons for usually preferring a layout with an "if" and
separate assignments, rather than a combined assignment, include:

1. It is clear when a given variable is assigned to. I believe it is
important to know what can be changed by a piece of code, and where each
piece of data can be changed. Along with this goes a bias towards
having multiple return value functions return structs (or tuples) rather
than taking a pointer to an variable to change. In my opinion it makes
it easier to see the data flow.

2. It is easier to change code if you later need to do other things in
connection with the conditional (i.e., if you want to do something else
when "x == y" other than assign "c" to "a").

3. A code layout with separate statements and avoiding doing too many
things in one line works much better with tools for version control or
comparison (diff tools) - it is easier to see what has changed and what
has not changed.

4. In my line of programming, C is dominant - the proportion of C++
coding is increasing, but still much less than C. And a sizeable
proportion of small-systems embedded programmers have a background from
hardware and electronics, rather than some kind of computer science
degree. This gives a different viewpoint and different experiences,
which can be a good thing and a bad thing (teams with mixed backgrounds
are useful). But it means that you sometimes have to be careful with
coding techniques that are relatively uncommon - there is a balance to
be found between confusing other people and having an opportunity to
teach new ideas. The kind of coding you use can be very different for a
dedicated team of higher-level, experienced C++ coders and when you are
working with one or two people who cover a broad range of tasks from
electronics design through to simple programming tasks. That does not
mean that "lowest common denominator" programming is the right tactic,
but you may have to have more justification before using a technique
that has a high chance of being unfamiliar.

5. Code needs to be tested and debugged. When dealing with
small-systems embedded work, techniques like simulation or unit testing
are often impractical or impossible - much of the close-to-the-metal
coding can only be tested in-system. Spacing out the code more makes it
far easier add breakpoints, logging, volatile variables, and other
debugging aids.

6. Sometimes code must be commented. I'm a great fan of expressing
things in code rather than in comments, by use of good names, clear
code, static asserts, etc., but comments are useful. With compact code,
it is rarely possible to put comments close to the action.

7. Sometimes the results from more compact form are significantly less
efficient. A quick test suggests that gcc on x86 will give the same
object code for an "if" with separate assignments as "(x == y ? a : b) =
c;". But the C equivalent, "*(x == y ? &a : &b) = c;", is massively
inefficient for local variables that would otherwise reside in
registers. (gcc is usually quite good at keeping local variables in
registers even if you take their address.) In the embedded world, some
compilers are not very good at optimising - I have seen the results of
conditional operator expressions produce very poor code even in the
right-hand side of expressions.

8. Coding standards often limit such expressions, whether or not a
particular programmer might think it is a good idea. If an embedded
programmer is working to the MISRA standards (which is common in the
industry), then even "c = (x == y ? a : b);" is not allowed - it must be
written "c = ((x == y) ? a : b);" or "c = (x == y) ? a : b;", and there
are limits to the complexities of the expressions "a" and "b".

>
> 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.

I think it is fairly obvious what the expression does - though not
obvious that it is allowed by the language (particularly because it is
allowed in C++ but not in C). However, just because it could only mean
one thing does not make it easy to follow - and if the reader is using
more effort to understand the mechanics of what the code is doing, they
have less brain power available for the important part - /why/ the code
is doing what it does.

>
> 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.

Indeed - and I think we all agree that context and names are vital, and
that the clearest way to express something in code depends on wider
circumstances and cannot be covered by simple fixed rules.

[James Kuyper]

On 11/6/21 7:25 AM, David Brown wrote:
...

> "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.

That reminds me a little too painfully of a subordinate that I knew to
be incompetent, and suspected of being literally insane. After his
actions got him reassigned with no replacement, I was left with the job
of maintaining the code he'd written. It was bug-ridden, untested,
inconsistent with the design documents, and he'd managed to accidentally
erase all of the revision history for many of the files he'd worked on
(I managed to get some of that history restored from backup).
After his reassignment, he behaved in odd and vaguely threatening ways
to me, such as stopping outside my office and just staring at me for
long periods of time. Around that time I happened to receive some
paperwork connected with his reassignment, which had home address on it,
and I learned that he lived less than 100 meters from me. So I was the
one who knew where he lived. I'm glad it was NOT the other way around.