• That's while I love C++ over C

    From Bonita Montero@21:1/5 to All on Wed Nov 3 20:39:16 2021
    (x == y ? a : b) = c;

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart@21:1/5 to Bonita Montero on Wed Nov 3 20:28:38 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Vir Campestris@21:1/5 to Bart on Fri Nov 5 21:59:46 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Vir Campestris on Fri Nov 5 17:25:40 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From red floyd@21:1/5 to Lynn McGuire on Fri Nov 5 16:24:08 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart@21:1/5 to Vir Campestris on Fri Nov 5 23:35:15 2021
    On 05/11/2021 21:59, 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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart@21:1/5 to red floyd on Fri Nov 5 23:46:58 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tony Oliver@21:1/5 to Bart on Fri Nov 5 17:48:00 2021
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart@21:1/5 to Tony Oliver on Sat Nov 6 01:40:35 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Tony Oliver on Sat Nov 6 02:32:02 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Alf P. Steinbach@21:1/5 to red floyd on Sat Nov 6 04:48:08 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From red floyd@21:1/5 to Ben Bacarisse on Fri Nov 5 20:18:53 2021
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris M. Thomasson@21:1/5 to red floyd on Fri Nov 5 21:59:14 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Kuyper@21:1/5 to Alf P. Steinbach on Sat Nov 6 00:34:22 2021
    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".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From red floyd@21:1/5 to Chris M. Thomasson on Fri Nov 5 22:27:45 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris M. Thomasson@21:1/5 to red floyd on Fri Nov 5 22:46:14 2021
    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;
    }
    _____________

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From red floyd@21:1/5 to red floyd on Fri Nov 5 22:28:29 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris M. Thomasson@21:1/5 to Chris M. Thomasson on Fri Nov 5 22:23:21 2021
    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!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From red floyd@21:1/5 to Alf P. Steinbach on Fri Nov 5 22:26:11 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to James Kuyper on Fri Nov 5 22:48:34 2021
    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 */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to red floyd on Fri Nov 5 22:46:50 2021
    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 */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Nov 6 07:33:56 2021
    Am 05.11.2021 um 22:59 schrieb Vir Campestris:
    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.

    That's just a matter of habits and taste.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ike Naar@21:1/5 to red floyd on Sat Nov 6 06:59:38 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Nov 6 07:36:42 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Nov 6 07:37:19 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Bart on Sat Nov 6 10:58:07 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to red floyd on Sat Nov 6 11:12:17 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to red floyd on Sat Nov 6 11:08:04 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart@21:1/5 to David Brown on Sat Nov 6 12:00:35 2021
    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.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart@21:1/5 to red floyd on Sat Nov 6 11:44:10 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Keith Thompson on Sat Nov 6 12:25:58 2021
    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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Sat Nov 6 15:03:13 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Bart on Sat Nov 6 13:18:58 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?w5bDtiBUaWli?=@21:1/5 to Bart on Sat Nov 6 07:04:12 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Bart on Sat Nov 6 15:50:16 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Bart on Sat Nov 6 14:43:07 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Scott Lurndal on Sat Nov 6 17:13:52 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Manfred@21:1/5 to Ben Bacarisse on Sat Nov 6 19:12:51 2021
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart@21:1/5 to Manfred on Sat Nov 6 18:57:32 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Scott Lurndal on Sat Nov 6 20:25:13 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Manfred on Sat Nov 6 20:50:36 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Keith Thompson@21:1/5 to David Brown on Sat Nov 6 13:27:27 2021
    David Brown <david.brown@hesbynett.no> writes:
    On 06/11/2021 06:46, Keith Thompson wrote:
    red floyd <no.spam.here@its.invalid> writes:
    [...]
    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;
    }

    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.

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Ben Bacarisse on Sat Nov 6 20:16:06 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Manfred@21:1/5 to Keith Thompson on Sun Nov 7 00:38:57 2021
    On 11/6/2021 9:27 PM, Keith Thompson wrote:
    David Brown <david.brown@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 */

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ben Bacarisse@21:1/5 to Manfred on Sun Nov 7 00:33:14 2021
    Manfred <noname@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Keith Thompson on Sun Nov 7 15:10:10 2021
    On 06/11/2021 21:27, Keith Thompson wrote:
    David Brown <david.brown@hesbynett.no> writes:
    On 06/11/2021 06:46, Keith Thompson wrote:
    red floyd <no.spam.here@its.invalid> writes:
    [...]
    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;
    }

    To be clear, I respect your opinion. I just don't share it in this
    case.

    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.


    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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From James Kuyper@21:1/5 to David Brown on Mon Nov 8 01:47:27 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)