Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82194 > unrolled thread

That's while I love C++ over C

Back to article view | Back to comp.lang.c++

Contents

  That's while I love C++ over C Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-03 20:39 +0100
    Re: That's while I love C++ over C Bart <bc@freeuk.com> - 2021-11-03 20:28 +0000
      Re: That's while I love C++ over C Vir Campestris <vir.campestris@invalid.invalid> - 2021-11-05 21:59 +0000
        Re: That's while I love C++ over C Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-05 17:25 -0500
          Re: That's while I love C++ over C red floyd <no.spam.here@its.invalid> - 2021-11-05 16:24 -0700
            Re: That's while I love C++ over C Bart <bc@freeuk.com> - 2021-11-05 23:46 +0000
              Re: That's while I love C++ over C Tony Oliver <guinness.tony@gmail.com> - 2021-11-05 17:48 -0700
                Re: That's while I love C++ over C Bart <bc@freeuk.com> - 2021-11-06 01:40 +0000
                Re: That's while I love C++ over C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-06 02:32 +0000
                  Re: That's while I love C++ over C red floyd <no.spam.here@its.invalid> - 2021-11-05 20:18 -0700
                    Re: That's while I love C++ over C "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-11-06 04:48 +0100
                      Re: That's while I love C++ over C James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-06 00:34 -0400
                        Re: That's while I love C++ over C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-05 22:48 -0700
                      Re: That's while I love C++ over C red floyd <no.spam.here@its.invalid> - 2021-11-05 22:26 -0700
                        Re: That's while I love C++ over C Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-06 07:37 +0100
                    Re: That's while I love C++ over C Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-06 07:36 +0100
                    Re: That's while I love C++ over C Ike Naar <ike@sdf.org> - 2021-11-06 06:59 +0000
                    Re: That's while I love C++ over C David Brown <david.brown@hesbynett.no> - 2021-11-06 11:12 +0100
                    Re: That's while I love C++ over C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-06 11:08 +0000
                      Re: That's while I love C++ over C Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-06 15:03 +0100
                      Re: That's while I love C++ over C Manfred <noname@add.invalid> - 2021-11-06 19:12 +0100
                        Re: That's while I love C++ over C Bart <bc@freeuk.com> - 2021-11-06 18:57 +0000
                        Re: That's while I love C++ over C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-06 20:50 +0000
                    Re: That's while I love C++ over C Bart <bc@freeuk.com> - 2021-11-06 11:44 +0000
                      Re: That's while I love C++ over C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-06 13:18 +0000
              Re: That's while I love C++ over C David Brown <david.brown@hesbynett.no> - 2021-11-06 10:58 +0100
                Re: That's while I love C++ over C Bart <bc@freeuk.com> - 2021-11-06 12:00 +0000
                  Re: That's while I love C++ over C Öö Tiib <ootiib@hot.ee> - 2021-11-06 07:04 -0700
                  Re: That's while I love C++ over C David Brown <david.brown@hesbynett.no> - 2021-11-06 15:50 +0100
              Re: That's while I love C++ over C scott@slp53.sl.home (Scott Lurndal) - 2021-11-06 14:43 +0000
                [OT] Algol68 Was: That's while I love C++ over C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-06 17:13 +0000
                  Re: [OT] Algol68 Was: That's while I love C++ over C scott@slp53.sl.home (Scott Lurndal) - 2021-11-06 20:16 +0000
                    Re: [OT] Algol68 Was: That's while I love C++ over C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-06 20:25 +0000
            Re: That's while I love C++ over C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-05 21:59 -0700
              Re: That's while I love C++ over C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-05 22:23 -0700
                Re: That's while I love C++ over C red floyd <no.spam.here@its.invalid> - 2021-11-05 22:27 -0700
                  Re: That's while I love C++ over C red floyd <no.spam.here@its.invalid> - 2021-11-05 22:28 -0700
                    Re: That's while I love C++ over C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-05 22:46 -0700
                  Re: That's while I love C++ over C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-05 22:46 -0700
                    Re: That's while I love C++ over C David Brown <david.brown@hesbynett.no> - 2021-11-06 12:25 +0100
                      Re: That's while I love C++ over C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-06 13:27 -0700
                        Re: That's while I love C++ over C Manfred <noname@add.invalid> - 2021-11-07 00:38 +0100
                          Re: That's while I love C++ over C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-07 00:33 +0000
                        Re: That's while I love C++ over C David Brown <david.brown@hesbynett.no> - 2021-11-07 15:10 +0100
                      Re: That's while I love C++ over C James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-08 01:47 -0500
        Re: That's while I love C++ over C Bart <bc@freeuk.com> - 2021-11-05 23:35 +0000
        Re: That's while I love C++ over C Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-06 07:33 +0100

Page 1 of 3  [1] 2 3  Next page →

#82194 — That's while I love C++ over C

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

[toc] | [next] | [standalone]

#82195

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.

[toc] | [prev] | [next] | [standalone]

#82213

On 03/11/2021 20:28, Bart wrote:
> 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.

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

Any of those versions.

Andy

[toc] | [prev] | [next] | [standalone]

#82214

On 11/5/2021 4:59 PM, Vir Campestris wrote:
> On 03/11/2021 20:28, Bart wrote:
>> 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.
> 
> If you wrote that code in anything in my company I would downvote the 
> review.
> 
> Any of those versions.
> 
> Andy

I would fire him.

Lynn

[toc] | [prev] | [next] | [standalone]

#82215

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.

[toc] | [prev] | [next] | [standalone]

#82217

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.

[toc] | [prev] | [next] | [standalone]

#82219

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)

[toc] | [prev] | [next] | [standalone]

#82220

On 06/11/2021 00:48, Tony Oliver wrote:
> 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)


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.

[toc] | [prev] | [next] | [standalone]

#82221

Tony Oliver <guinness.tony@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.

[toc] | [prev] | [next] | [standalone]

#82222

On 11/5/2021 7:32 PM, Ben Bacarisse wrote:
> Tony Oliver <guinness.tony@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?
> 

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?

[toc] | [prev] | [next] | [standalone]

#82224

On 6 Nov 2021 04:18, red floyd wrote:
> On 11/5/2021 7:32 PM, Ben Bacarisse wrote:
>> Tony Oliver <guinness.tony@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?
>>
> 
> 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?

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

[toc] | [prev] | [next] | [standalone]

#82225

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

[toc] | [prev] | [next] | [standalone]

#82233

James Kuyper <jameskuyper@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.

[...]

-- 
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 */

[toc] | [prev] | [next] | [standalone]

#82228

On 11/5/2021 8:48 PM, Alf P. Steinbach wrote:
> On 6 Nov 2021 04:18, red floyd wrote:
>> On 11/5/2021 7:32 PM, Ben Bacarisse wrote:
>>> Tony Oliver <guinness.tony@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?
>>>
>>
>> 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?
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#82236

Am 06.11.2021 um 06:26 schrieb red floyd:
> On 11/5/2021 8:48 PM, Alf P. Steinbach wrote:
>> On 6 Nov 2021 04:18, red floyd wrote:
>>> On 11/5/2021 7:32 PM, Ben Bacarisse wrote:
>>>> Tony Oliver <guinness.tony@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?
>>>>
>>>
>>> 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?
>>
>> 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.

Absolutely not.

[toc] | [prev] | [next] | [standalone]

#82235

Am 06.11.2021 um 04:18 schrieb red floyd:
> On 11/5/2021 7:32 PM, Ben Bacarisse wrote:
>> Tony Oliver <guinness.tony@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?
>>
> 
> 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;

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.

[toc] | [prev] | [next] | [standalone]

#82237

On 2021-11-06, red floyd <no.spam.here@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.

[toc] | [prev] | [next] | [standalone]

#82239

On 06/11/2021 04:18, red floyd wrote:
> On 11/5/2021 7:32 PM, Ben Bacarisse wrote:
>> Tony Oliver <guinness.tony@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?
>>
> 
> 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?

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.

[toc] | [prev] | [next] | [standalone]

#82240

red floyd <no.spam.here@its.invalid> writes:

> On 11/5/2021 7:32 PM, Ben Bacarisse wrote:
>> Tony Oliver <guinness.tony@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?
>
> 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?

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.

[toc] | [prev] | [next] | [standalone]

#82245

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web