We have operators in the form 'op=' for all arithmetic(+ - * / %) and
bitwise(& | ^ << >>) binary operators op, but why not for logical(&& ||)
operators? Wouldn't it be nice to have &&=, ||= operators too?

I never write 'some_variable = some_variable op some_expression'
except for the case when op is && or ||.

--

--

elsewhere.  Try using this URL to see some of it:

 http://groups.google.com/groups?q=why+no+%26%26%3D+and+%7C%7C%3D+%3F

 - LarryW
--

I'll grant you it does seem inconsistent, but could you give a code
example where they would be useful?  With the way loops work in C/C++,
&&= ||= do not seem to be of high utility to me.
--

comp.lang.c.moderated:

And how often do you write 'some_variable = some_variable op
some_expression'?  It is not all that common in code I have seen, or
written.  Can you provide an actual example?  On the other hand,
"some_var &= some_flag" and "some_var |= some_flag" is rather more
common.

A binary operator with assignment requires that the left hand operand
be an lvalue, and in most cases when the && and || operators are used,
this is not so.  Consider:

return_type some_function(const char *cp)
{
   if (NULL != cp && '\0' != *cp)

Where is the lvalue there?  If you really wanted to, you could write
the expression:

   bool b = (NULL != cp && '\0' != *cp);

Or you could write:

   bool b = (NULL != cp);
   b &&= ('\0' != *cp);

But this discards one of the most important features of the logical
operators, their guaranteed short circuit operation.  In my first two
code snippets the behavior is safe from being passed a null pointer
because the pointer is never dereferenced to test for '\0' if it is
null.  In the third example, the second line invokes undefined
behavior if the pointer cp is NULL.  So you would have to add extra
code in many cases to simulate the same evaluation properties.

Again, can you provide some example code where the operators you ask
for would be useful, and where you couldn't accomplish the same thing
with bitwise & or |?

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
--

No.  && and || conceptually produce Boolean results while & | etc.
produce integer results.  &&= wouldn't fit the op= model.
How often do you think it would be used, really?
--

This is not a valid example, IMO:  for consistency, if the operators
&&= and ||= did exist, they would also do short-circuit evaluation
(i.e., if the left operand of &&= is false, then the entire expression
has no effect -- including, in particular, the fact that the right-
side is not evaluated;  same thing for ||= if the left operand is
true)

I do agree that splitting the common idiom

      return something && something else

into two lines (including the creation of a temporary bool variable)
would make it lose its beauty.

Carlos
--
--

Loops have nothing to do with it, it's an irrelevant argument.

One situation where e.g. &&= would be useful is in a sequence of
calls to functions returning boolean status codes instead of
throwing exceptions;

    bool ok = true;

    ok &&= f1( long argument list );
    ok &&= f2( long argument list );
    ok &&= f3( long argument list );
    ok &&= f4( long argument list );
    ok &&= f5( long argument list );
    return ok;

In this construction there would have to be the same short-
circuit evaluation as for infix notation, i.e. "ok &&= f()"
would have to be exactly equivalent to "ok = ok && f()".

But in general, providing a full repertoire of operations,
in the sense that the set of operations seems complete, is a
good thing in and of itself  --  regardless of whether one
can think of a concrete usage example.  It's axiomatic that
when an operation is "missing" from a set it will be missed.
That doesn't mean that every possible operation has to or
should be thrown in, but in a perfect design there would be
no obvious missing operations once the intention is clear.

Hth.,

- Alf
--

They *actually* produce bool results.

Fitness or not has nothing to do with the result type, e.g. * and /
produce various numerical type results, depending on the arguments.

Nobody uses the full language.  We each have our own preferred
subset.  Some would probably use these operators often; others
seldom if at all.  Do tell, how often do you use method pointers?
If "often", then that's indicative of bad design, but that's not
an argument for leaving them out of the language.

Cheers,

- Alf
--

Wrong.

Consider the * and / operators...

Hth.,

- Alf
--

Removing clc++m from the newsgroup list, as I don't know a thing about
C++.

I sometimes write

        p = p->next;

and would like to be able to write it

        p ->= next;

-andy
--

Thanks for the information.

To summarize:

1. There was no boolean type in C.
2. They don't represent a single machine instruction.
3. They are logical operators so not used in assignments very much.
4. They might cause confusion regarding the short-circuit behaviour
  and the evaluation order of the operands.

I feel the last one is the most compelling.

Anyway;

1. the presence of &= and |= doesn't justify the absence
  of &&= and ||=, just as & and | don't for && and ||.
  I don't want to use & or | for bools.

2. Perl already has &&= and ||=, which are short-circuited.

3. Still I think it would not hurt to have &&= and ||=. :-)
  (together with logical XOR operator ^^)

--

--

Yes, I agree and I haven't written very much that would benefit from
&&= and ||=. I didn't mean to insist that we should have them, but it's
just that I was very curious. :-)

Anyway that something is not very common doesn't weaken a proposal
that we should have it: do you use the operator ^= very often? :-)

I could give you only some artificial one like this:

    bool okay = true;
    // some processing
    okay &&= condition1;
    // some processing
    okay &&= condition2;
    // some processing
    okay &&= condition3;

In the case that I had thought of having &&= and ||= at first,
I soon found out that the operands should always be evaluated
so changed 'flag = flag || func()' to 'flag = func() || flag'.
Depending upon how we decide the semantics of &&= and ||= to be,
that can be rewritten with ||= or not.

Several other people have suggested examples.

<:">

<:">

--

--

Imagine the following fragment from an email program:
bool send(const char*);
bool responseOK();

bool stat = write("HELO ");
stat &&= write(m_ServerName);
stat &&= write(m_CRLF);
stat &&= responseOK();
stat &&= write("USER ");
stat &&= write(m_UserName);
... etc.

No claim here that &&= would be the *best* way to write this code, but it's
a decent one.  Actually I just converted the thing to exceptions, and I
think it's better that way.  But here's your proof-of-concept.
-- jkb
--