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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#82251

On 11/6/2021 12:08 PM, Ben Bacarisse wrote:
> 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.
> 

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)

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

#82252

On 06/11/2021 18:12, Manfred wrote:
> On 11/6/2021 12:08 PM, Ben Bacarisse wrote:
>> 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.
>>
> 
> 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.

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

#82256

Manfred <noname@add.invalid> writes:

> On 11/6/2021 12:08 PM, Ben Bacarisse wrote:
>> 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. 
>
> 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!

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

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

#82242

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.

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.

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

#82244

Bart <bc@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.

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

#82238

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

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

#82243

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

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

#82246

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.

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

#82248

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.

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

#82247

Bart <bc@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.

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

#82250 — [OT] Algol68 Was: That's while I love C++ over C

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

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

#82253 — Re: [OT] Algol68 Was: That's while I love C++ over C

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>scott@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?

Had to use it.

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

#82254 — Re: [OT] Algol68 Was: That's while I love C++ over C

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>scott@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?
>
> 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.

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

#82226

On 11/5/2021 4:24 PM, 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]
>>>
>>> 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.
> 

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

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

#82227

On 11/5/2021 9:59 PM, Chris M. Thomasson wrote:
> On 11/5/2021 4:24 PM, 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]
>>>>
>>>> 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.
>>
> 
> 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!

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

#82229

On 11/5/2021 10:23 PM, Chris M. Thomasson wrote:
> On 11/5/2021 9:59 PM, Chris M. Thomasson wrote:
>> On 11/5/2021 4:24 PM, 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]
>>>>>
>>>>> 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.
>>>
>>
>> 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!

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.

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

#82230

On 11/5/2021 10:27 PM, red floyd wrote:
> On 11/5/2021 10:23 PM, Chris M. Thomasson wrote:
>> On 11/5/2021 9:59 PM, Chris M. Thomasson wrote:
>>> On 11/5/2021 4:24 PM, 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]
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> 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!
> 
> 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.
> 
> 

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

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

#82231

On 11/5/2021 10:28 PM, red floyd wrote:
> On 11/5/2021 10:27 PM, red floyd wrote:
>> On 11/5/2021 10:23 PM, Chris M. Thomasson wrote:
>>> On 11/5/2021 9:59 PM, Chris M. Thomasson wrote:
>>>> On 11/5/2021 4:24 PM, 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]
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>
>>>> 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!
>>
>> 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.
>>
>>
> 
> 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;
}
_____________

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

#82232

red floyd <no.spam.here@its.invalid> writes:
> On 11/5/2021 10:23 PM, Chris M. Thomasson wrote:
>> On 11/5/2021 9:59 PM, Chris M. Thomasson wrote:
>>> On 11/5/2021 4:24 PM, 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]
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> 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!
>
> 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.

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

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

#82241

On 06/11/2021 06:46, Keith Thompson wrote:
> red floyd <no.spam.here@its.invalid> writes:
>> On 11/5/2021 10:23 PM, Chris M. Thomasson wrote:
>>> On 11/5/2021 9:59 PM, Chris M. Thomasson wrote:
>>>> On 11/5/2021 4:24 PM, 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]
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>
>>>> 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!
>>
>> 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.
> 
> 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.  

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.

> And creating a pointer variable:
> 
>     auto p = x == y ? &a : &b;
>     *p = c;
> 
> seems silly when you can just use the conditional operator directly.
> 

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web