Daniel Frey wrote:
> Well, the subjects says it all. How about it? Should these operators be
> added? Some pseudo-code:
>
> bool b = ...;
>
> b &&= foo(); // I want this
> b = b && foo(); // Works, but it's a pain of 'b' is a long identifier
> b &= foo(); // Doesn't short-circuit like the line above :(

Maybe the inventors of C thought they would be entering a rat's nest if
they provided assignment operations for ops that returned booleans. For
example, one would expect shortcuts for the following:

  a = a == b;
  a = a != b;
  a = a > b;
  a = a < b;
  a = a <= b;
  a = a >= b;
  a = !(a);

By applying the {op}= idea, you get results that in some cases are
ambiguous, and in other cases could be the result of typos:

  a === b;
  a !== b;
  a >= b;
  a <= b;
  a <== b;
  a >== b;
  a != a;


My 2 cents,
Derek.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
>
> In article <3e25ebc6@news.toast.net>, The Axe-Wielding Fuddite
> <scottm@toast.net> writes
> >On the other hand, it's annoying to teach someone that a &= b
> >works but a &&= b doesn't. There's something to be said for
> >having the set of operators be complete and regular. And I'd
> >be surprised if this amounted to a large burden on compilers.
>
> A teacher who is not making a clear distinction between bitwise and
> logical operators is not do his job correctly. I would much prefer not
> to have to explain what &&= might mean, particularly as it requires
> multiple conversions if the lhs is not a bool.

Prehaps if &&= and ||= were added to C++ they should only be defined for
boolean types on the lhs, and allowed as overloaded operators in classes.

I see at least three "obvious" but different meanings for non-boolean lhs:

1. The perl way...
---------------------------------
Treat
  x &&= y;
as if it were
  if (standard_cast<bool>(x)) {
    x = y;
  }

And treat
  x ||= y;
as if it were
  if (!standard_cast<bool>(x)) {
    x = y;
  }
---------------------------------

2. Or convert only rhs to bool approach
---------------------------------
Ie treat
  x &&= y;
as if it were
  if (standard_cast<bool>(x)) {
    x = standard_cast<bool>(y);
  }

And treat
  x ||= y;
as if it were
  if (!standard_cast<bool>(x)) {
    x = standard_cast<bool>(y);
  }
---------------------------------

3. Or convert both to bool approach
---------------------------------
Ie treat
  x &&= y;
as if it were
  if (standard_cast<bool>(x)) {
    x = standard_cast<bool>(y);
  } else {
    x = false;
  }

And treat
  x ||= y;
as if it were
  if (!standard_cast<bool>(x)) {
    x = standard_cast<bool>(y);
  } else {
    x = true;
  }
---------------------------------

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen <hyrosen@mail.com> wrote:
+ thp@cs.ucr.edu wrote:
+> Hyman Rosen <hyrosen@mail.com> wrote:
+> +        bool &b = a_very_long_and_complicated_expression;
+> +        if (b)  b = and_then; // or, b = b && and_then;
+>
+> you solution still has the problem of having
+> of writing the complex lvalue twices
+
+ Huh? The complex lvalue is written once, and a reference
+ is created to it. Then the refernce is used as needed.
+ That "b" up there is an actual name.

Oops.  Somehow, I missed your point.  (It appears that I had lost my
sense of grammar and spelling as well.)

It would be nice to have a solution that is an expression designating
the possibly modified object in the usual "x op= y" fashion.

Tom Payne

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0301161131.6abb4349@posting.google.com...
> I think you're missing the gist of the proposal. Daniel Frey wants
> to use operator &&= and ||= with the obvious implied meaning, including
> short-circuit evaluation for built-in types.

Duh, of course you're right.

I completely forgot a user defined operator&& has different behaviour than
the implicit one - and presumably this would also be true for a hypothetical
operator &&=

Sorry.
Roger.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

thp@cs.ucr.edu wrote:
> Hyman Rosen <hyrosen@mail.com> wrote:
> +        bool &b = a_very_long_and_complicated_expression;
> +        if (b)  b = and_then; // or, b = b && and_then;
>
> you solution still has the problem of having
> of writing the complex lvalue twices

Huh? The complex lvalue is written once, and a reference
is created to it. Then the refernce is used as needed.
That "b" up there is an actual name.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

thp@cs.ucr.edu wrote:
> The benefit of the proposed solution is that, in cases where b is a
> complicated lvalue, the program's author doesn't have to write "b"
> twice, and the programs reader doesn't have to check whether both b's
> are identical.

This probably comes up infrequently, but when it does in C++,
you can always write

 bool &b = a_very_long_and_complicated_expression;
 if (b)  b = and_then; // or, b = b && and_then;
 if (!b) b = or_else;  // or, b = b || or_else;

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>I'd guess that an opportunity to use &&= and ++= arises only a few
> times in an entire program.
>
> There's also an Pandora effect to avoid.  Once C++ starts expanding the
set of
> operators there's no effective limit on the set of operators with non-zero
> utility.  So a minimum threshold of utility has to be maintained.

On the other hand, it's annoying to teach someone that a &= b
works but a &&= b doesn't. There's something to be said for
having the set of operators be complete and regular. And I'd
be surprised if this amounted to a large burden on compilers.




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1042582753.932792@master.nyc.kbcfp.com...
> thp@cs.ucr.edu wrote:

> This probably comes up infrequently, but when it does in C++,
> you can always write


Alternatively you can use a named function to save the typing:

// Simulate &&=
bool & andeq( bool &lhs, const bool &rhs )
{
    return lhs = lhs && rhs;
}

class C
{
public:
    bool & getBool( int i, int j ) { return b; }
private:
    bool b;
};

int main( int argc, char **argv )
{
    C c;
    bool aBool( false );
    andeq( c.getBool( 1, 3 ), aBool );

    return 0;
}

Iin my view, given the relative scarcity of the problem, the additional
complexity to the language outweighs the benefit.

Roger Orr
--
MVP in C++ at www.brainbench.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3e25ebc6@news.toast.net>, The Axe-Wielding Fuddite
<scottm@toast.net> writes
>On the other hand, it's annoying to teach someone that a &= b
>works but a &&= b doesn't. There's something to be said for
>having the set of operators be complete and regular. And I'd
>be surprised if this amounted to a large burden on compilers.

A teacher who is not making a clear distinction between bitwise and
logical operators is not do his job correctly. I would much prefer not
to have to explain what &&= might mean, particularly as it requires
multiple conversions if the lhs is not a bool.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hyman Rosen <hyrosen@mail.com> wrote:
+ thp@cs.ucr.edu wrote:
+> The benefit of the proposed solution is that, in cases where b is a
+> complicated lvalue, the program's author doesn't have to write "b"
+> twice, and the programs reader doesn't have to check whether both b's
+> are identical.
+
+ This probably comes up infrequently, but when it does in C++,
+ you can always write
+
+        bool &b = a_very_long_and_complicated_expression;
+        if (b)  b = and_then; // or, b = b && and_then;
+        if (!b) b = or_else;  // or, b = b || or_else;

In dealing with templates, it seems to come more frequently that I
would have expected, and you solution still has the problem of having
of writing the complex lvalue twices and of checking that both
instances are the same.

Tom Payne

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

The Axe-Wielding Fuddite wrote:

> >I'd guess that an opportunity to use &&= and ++= arises only a few
> > times in an entire program.
> >
> > There's also an Pandora effect to avoid.  Once C++ starts expanding the
> set of
> > operators there's no effective limit on the set of operators with non-zero
> > utility.  So a minimum threshold of utility has to be maintained.
>
> On the other hand, it's annoying to teach someone that a &= b
> works but a &&= b doesn't. There's something to be said for
> having the set of operators be complete and regular. And I'd
> be surprised if this amounted to a large burden on compilers.

The irregular set of operators is far less annoying than the distinction between
fundamental types and UDTs as operands.  C++ is a patchwork and we have to live
with it as an incremental improvement over C.

In that vein, &&= is not particularly more valuable in C++ than in C.  So if
operator regularity is important it ought to apply to the base language even
more than it does in the derived language.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Roger Orr" <rogero@howzatt.demon.co.uk> wrote:
+ "Hyman Rosen" <hyrosen@mail.com> wrote in message
+ news:1042582753.932792@master.nyc.kbcfp.com...
+> thp@cs.ucr.edu wrote:
+
+> This probably comes up infrequently, but when it does in C++,
+> you can always write
+
+
+ Alternatively you can use a named function to save the typing:
+
+ // Simulate &&=
+ bool & andeq( bool &lhs, const bool &rhs )
+ {
+    return lhs = lhs && rhs;
+ }

That's not equivalent to the proposed operator, unless you can get
your function to do short-circuit evaluation of its arguments.

Tom Payne

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> "Hyman Rosen" <hyrosen@mail.com> wrote
> > This probably comes up infrequently, but when it does in C++,
> > you can always write
[reinserting snipped examples]
> >  bool &b = a_very_long_and_complicated_expression;
> >  if (b)  b = and_then; // or, b = b && and_then;
> >  if (!b) b = or_else;  // or, b = b || or_else;

rogero@howzatt.demon.co.uk ("Roger Orr") wrote
> Alternatively you can use a named function to save the typing:
>
> // Simulate &&=
> bool & andeq( bool &lhs, const bool &rhs )
> {
>     return lhs = lhs && rhs;
> }
>
> class C
> {
> public:
>     bool & getBool( int i, int j ) { return b; }
> private:
>     bool b;
> };
>
> int main( int argc, char **argv )
> {
>     C c;
>     bool aBool( false );
>     andeq( c.getBool( 1, 3 ), aBool );
>
>     return 0;
> }
>
> Iin my view, given the relative scarcity of the problem, the additional
> complexity to the language outweighs the benefit.

I think you're missing the gist of the proposal. Daniel Frey wants
to use operator &&= and ||= with the obvious implied meaning, including
short-circuit evaluation for built-in types. Hyman Rosen's examples
do the equivalent of the short-circuits. Your function does not.

    bool valid;
    int i, j;
    // ...
    valid = (j>0);
    // ...
    valid &&= ((i/j)>5); // This line!

Hyman Rosen's equivalents for the last line all manage to avoid division
by zero:
    if (valid) valid = ((i/j)>5);
    // or
    valid = valid && ((i/j)>5);

Your andeq() function does not:
    andeq(valid, ((i/j)>5)); // Division by zero!
because the rightmost expression ((i/j)>5) is evaluated before the
function is called.

The closest we could come is a macro:
    #define andeq(lhs,rhs) ((lhs)?(lhs)=(rhs):false)
with all the complications that arise (such as potentially evaluating
lhs twice).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Frey <daniel.frey@aixigo.de> wrote:
+ Well, the subjects says it all. How about it? Should these operators be
+ added? Some pseudo-code:
+
+ bool b = ...;
+
+ b &&= foo(); // I want this
+ b = b && foo(); // Works, but it's a pain of 'b' is a long identifier

This proposal leads to more readable code in cases where b is a
complicated boolean lvalue.

Tom Payne

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:

In general, please try to avoid "me too" posts that do not add further
information, viewpoints or arguments to a position.



===================================== END OF MODERATOR'S COMMENT

<thp@cs.ucr.edu> wrote in message news:avpnlj$dtn$1@glue.ucr.edu...
> Daniel Frey <daniel.frey@aixigo.de> wrote:
> + Well, the subjects says it all. How about it? Should these operators be
> + added? Some pseudo-code:
> +
> + bool b = ...;
> +
> + b &&= foo(); // I want this
> + b = b && foo(); // Works, but it's a pain of 'b' is a long identifier
>
> This proposal leads to more readable code in cases where b is a
> complicated boolean lvalue.

agreed.

Thorsten Ottosen


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Frey wrote:
 > Well, the subjects says it all. How about it? Should these operators
 > be added? Some pseudo-code:
 >
 > bool b = ...;
 >
 > b &&= foo(); // I want this b = b && foo(); // Works, but it's a pain
 > of 'b' is a long identifier b &= foo(); // Doesn't short-circuit like
 > the line above :(
 >
How do you do short-circuit evaluation with user defined overloading of
operator &&= and ||= for non-builtin types.

Peter Roozemaal

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

The need in &&= and ||= is so rare that it was considered
unnecessary, I suppose.  I wouldn't cry if they don't get added.

Victor
--
Please remove capital A's from my address when replying by mail

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Frey wrote:
>
> Well, the subjects says it all. How about it? Should these operators be
> added? Some pseudo-code:
>
> bool b = ...;
>
> b &&= foo(); // I want this
> b = b && foo(); // Works, but it's a pain of 'b' is a long identifier
> b &= foo(); // Doesn't short-circuit like the line above :(
>
> Opinions?

This topic has been discussed before: see this thread
<http://groups.google.com/groups?threadm=clcm-20020720-0001%40plethora.net&hl=en>.
(This thread has discussion on many other topics, though.)

--
KIM Seungbeom <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Peter Roozemaal" <dont.spam.mathfox@xs4all.nl> wrote
> How do you do short-circuit evaluation with user defined overloading of
> operator &&= and ||= for non-builtin types.

   You don't, for the same reason that short-circuiting doesn't work for
overloaded versions of operator&& and operator|| .

Joe Gottman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Daniel Frey wrote:

> Well, the subjects says it all. How about it? Should these operators be
> added? Some pseudo-code:
>
> bool b = ...;
>
> b &&= foo(); // I want this
> b = b && foo(); // Works, but it's a pain of 'b' is a long identifier
> b &= foo(); // Doesn't short-circuit like the line above :(
>
> Opinions?

Useful but marginal.  Your second example captures all of the value of the
concept -- probably not enough.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<thp@cs.ucr.edu> wrote in message news:avpnlj$dtn$1@glue.ucr.edu...
> Daniel Frey <daniel.frey@aixigo.de> wrote:
> + Well, the subjects says it all. How about it? Should these operators be
> + added? Some pseudo-code:
> +
> + bool b = ...;
> +
> + b &&= foo(); // I want this
> + b = b && foo(); // Works, but it's a pain of 'b' is a long identifier
>
> This proposal leads to more readable code in cases where b is a
> complicated boolean lvalue.

But that's not the most important advantage; things get especially nice
when the receiver is a computed expression:

array[index] &&= foo();


Andrei


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sun, 12 Jan 2003 03:18:56 +0100, Peter Roozemaal wrote:

> Daniel Frey wrote:
>  > Well, the subjects says it all. How about it? Should these operators
>  > be added? Some pseudo-code:
>  >
>  > bool b = ...;
>  >
>  > b &&= foo(); // I want this b = b && foo(); // Works, but it's a pain
>  > of 'b' is a long identifier b &= foo(); // Doesn't short-circuit like
>  > the line above :(
>  >
> How do you do short-circuit evaluation with user defined overloading of
> operator &&= and ||= for non-builtin types.

The same way it is solved for && and ||: No short-circuiting :o)

(Yes, this is ugly, but it's no worse as for user-defined operator&&'s. A
real solution to this problem is also desirable, but that's another
thing).

OK, given that is has been discussed before, I should read some more
stuff from these discussion... Thanks everyone :)

Regards, Daniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Sat, 11 Jan 2003 17:23:44 +0000 (UTC), daniel.frey@aixigo.de
(Daniel Frey) wrote in comp.std.c++:

> Well, the subjects says it all. How about it? Should these operators be
> added? Some pseudo-code:
>
> bool b = ...;
>
> b &&= foo(); // I want this
> b = b && foo(); // Works, but it's a pain of 'b' is a long identifier
> b &= foo(); // Doesn't short-circuit like the line above :(
>
> Opinions?
>
> Regards, Daniel

There are several other ways of writing the expression that do short
circuit:

if (!b)
   b = foo();

....or...

b = b ? true : foo();

And similar statements for ||=.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jack Klein wrote:
>=20
> On Sat, 11 Jan 2003 17:23:44 +0000 (UTC), daniel.frey@aixigo.de
> (Daniel Frey) wrote in comp.std.c++:
>=20
> > Well, the subjects says it all. How about it? Should these operators =
be
> > added? Some pseudo-code:
> >
> > bool b =3D ...;
> >
> > b &&=3D foo(); // I want this
> > b =3D b && foo(); // Works, but it's a pain of 'b' is a long identifi=
er
> > b &=3D foo(); // Doesn't short-circuit like the line above :(
> >
> > Opinions?
> >
> > Regards, Daniel
>=20
> There are several other ways of writing the expression that do short
> circuit:
>=20
> if (!b)
>    b =3D foo();
>=20
> ....or...
>=20
> b =3D b ? true : foo();

The question is IMHO not whether or not I can write it in some way that
works, the question is how far the code differs from my thoughts. Code
(to me) is documentation, thus if I have a boolean value and I want to
&&=3D it, I would like to be able to write the code done. As you can see
from the last sentence, I don't even have a word for it, but this symbol
&&=3D represents best what I am thinking of. If semantically some other
way is meant, I wouldn't hesitate to write it like you showed above, but
if this is not the way I was thinking, the code "lies". C++ is
complicated enough so anything which helps me to express my thought more
direct would be a win, YMMV :)

Regards, Daniel

--=20
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrei Alexandrescu wrote:
>=20
> But that's not the most important advantage; things get especially nice
> when the receiver is a computed expression:
>=20
> array[index] &&=3D foo();

Something similar was the root of my question, except that array[index]
was about 4 times as long :) I think every feature people request has
some good uses, the question is how they compare to the drawbacks. I
don't see any technical drawbacks for &&=3D and ||=3D, it's just that you
have to "learn" two more operators. No currently legal code is affected,
the similarity to && and || make the meaning "obvious", so: Do you (or
anybody else here) know of any problems that are killer-arguments
against these operators which I missed?

Regards, Daniel

--=20
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jack Klein <jackklein@spamcop.net> wrote:
+ On Sat, 11 Jan 2003 17:23:44 +0000 (UTC), daniel.frey@aixigo.de
+ (Daniel Frey) wrote in comp.std.c++:
+
+> Well, the subjects says it all. How about it? Should these operators be
+> added? Some pseudo-code:
+>
+> bool b = ...;
+>
+> b &&= foo(); // I want this
+> b = b && foo(); // Works, but it's a pain of 'b' is a long identifier
+> b &= foo(); // Doesn't short-circuit like the line above :(
+>
+> Opinions?
+>
+> Regards, Daniel
+
+ There are several other ways of writing the expression that do short
+ circuit:
+
+ if (!b)
+   b = foo();
+
+ ....or...
+
+ b = b ? true : foo();

The benefit of the proposed solution is that, in cases where b is a
complicated lvalue, the program's author doesn't have to write "b"
twice, and the programs reader doesn't have to check whether both b's
are identical.

Tom Payne

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Witless" <witless@attbi.com> wrote in message
news:3E20A66C.175C2B93@attbi.com...
> Daniel Frey wrote:
>
> > Well, the subjects says it all. How about it? Should these operators be
> > added? Some pseudo-code:
> >
> > bool b = ...;
> >
> > b &&= foo(); // I want this
> > b = b && foo(); // Works, but it's a pain of 'b' is a long identifier
> > b &= foo(); // Doesn't short-circuit like the line above :(
> >
> > Opinions?
>
> Useful but marginal.  Your second example captures all of the value of the
> concept -- probably not enough.
>

so why don't we just use
   counter = counter + 1;
instead of
   ++counter;
?

hys

--
(c) 2003 Hillel Y. Sims
hsims AT factset.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Hillel Y. Sims" wrote:

> "Witless" <witless@attbi.com> wrote in message
> news:3E20A66C.175C2B93@attbi.com...
> > Daniel Frey wrote:
> >
> > > Well, the subjects says it all. How about it? Should these operators be
> > > added? Some pseudo-code:
> > >
> > > bool b = ...;
> > >
> > > b &&= foo(); // I want this
> > > b = b && foo(); // Works, but it's a pain of 'b' is a long identifier
> > > b &= foo(); // Doesn't short-circuit like the line above :(
> > >
> > > Opinions?
> >
> > Useful but marginal.  Your second example captures all of the value of the
> > concept -- probably not enough.
> >
>
> so why don't we just use
>    counter = counter + 1;
> instead of
>    ++counter;
> ?

Without counting I'd guess that I use ++ and -- several times per page of code.
They are particularly useful in concise idioms such as *p++.  Again, without
counting, I'd guess that an opportunity to use &&= and ++= arises only a few
times in an entire program.

There's also an Pandora effect to avoid.  Once C++ starts expanding the set of
operators there's no effective limit on the set of operators with non-zero
utility.  So a minimum threshold of utility has to be maintained.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Well, the subjects says it all. How about it? Should these operators be
added? Some pseudo-code:

bool b =3D ...;

b &&=3D foo(); // I want this
b =3D b && foo(); // Works, but it's a pain of 'b' is a long identifier
b &=3D foo(); // Doesn't short-circuit like the line above :(

Opinions?

Regards, Daniel

--=20
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]