• Matthias Becker (4/4) Feb 11 2004 Why is there no &&= nor ||= ind D?
• J Anderson (5/10) Feb 11 2004 I can't see that being used much. All that extra work for the compiler
• Phill (7/20) Feb 11 2004 There is a bit of that in Dig, or at least
• Matthias Becker (1/6) Feb 12 2004 Yes, but they don't have this short cirquit behavior.
• Matthias Becker (1/11) Feb 12 2004 How often do you use %= ?
• Antti =?iso-8859-1?Q?Syk=E4ri?= (28/40) Feb 12 2004 Occasionally. It's nice operator to have around when you want to modify
• edgein123 aol.com (42/81) Feb 12 2004 I must agree that there is no need for a &&= or ||= operator. Furthermor...
• Derek Parnell (17/79) Feb 12 2004 [snip]
• edgein123 aol.com (6/92) Feb 12 2004 My point was that programmers almost always use, and rely on, the short ...
• Hauke Duden (4/7) Feb 12 2004 Sweeping generalizations are always wrong!
• Manfred Nowak (4/8) Feb 12 2004 you are forgetting bit manipulations.
• Matthias Becker (6/11) Feb 13 2004 Ahh, don't say this. I use it all the time:
• Eric Decker (8/19) Feb 13 2004 This is actually the point I was trying to make. People almost always us...
• Matthias Becker (3/10) Feb 13 2004 Of course, the expressions shouldn't have any sideeffects.
• J Anderson (8/36) Feb 13 2004 I use the non-short-circuit version for logical binary operations. ie
• Matthew (34/74) Feb 22 2004 Okay,
• Juan C (51/62) Feb 12 2004
• Matthew (5/22) Feb 22 2004 yes, yes, yes, yes, yes, yes!!!
• Nam (7/33) Mar 02 2004 Sorry but I don't know clealy about &&=
• Matthias Becker (7/12) Mar 02 2004 ???

Matthias Becker <Matthias_member pathlink.com> writes:

Why is there no &&= nor ||= ind D?

bool foo;

So something like this should be possible:
foo &&= bar();

J Anderson <REMOVEanderson badmama.com.au> writes:

Matthias Becker wrote:

Why is there no &&= nor ||= ind D?

bool foo;

So something like this should be possible:
foo &&= bar();
  

I can't see that being used much.  All that extra work for the compiler 
writer for little gain.

-- 
-Anderson: http://badmama.com.au/~anderson/

"Phill" <phill pacific.net.au> writes:

There is a bit of that in Dig, or at least

|=
and
&= ~

Phill.


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:c0elqc$1lme$1 digitaldaemon.com...
 Matthias Becker wrote:

Why is there no &&= nor ||= ind D?

bool foo;

So something like this should be possible:
foo &&= bar();

 I can't see that being used much.  All that extra work for the compiler
 writer for little gain.

 --
 -Anderson: http://badmama.com.au/~anderson/

Matthias Becker <Matthias_member pathlink.com> writes:

There is a bit of that in Dig, or at least

|=
and
&= ~

Phill.

Yes, but they don't have this short cirquit behavior.

Matthias Becker <Matthias_member pathlink.com> writes:

Why is there no &&= nor ||= ind D?

bool foo;

So something like this should be possible:
foo &&= bar();
  

I can't see that being used much.  All that extra work for the compiler 
writer for little gain.

How often do you use %= ?

Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:

In article <c0fegm$2u05$1 digitaldaemon.com>, Matthias Becker wrote:
Why is there no &&= nor ||= ind D?

bool foo;

So something like this should be possible:
foo &&= bar();
  

I can't see that being used much.  All that extra work for the compiler 
writer for little gain.

 
 How often do you use %= ?

Occasionally. It's nice operator to have around when you want to modify
the index to a circular buffer and keep it in the valid range.

But I've never thought of using &&=, maybe simply because there isn't
one. And I've only seen &= used once or twice. Logically it makes sense,
though, since almost all other operators have an assignment equivalent.

And "&&=" would provide one way of handling errors and cleaning up
properly (if you don't want to use RAII or goto):

bool f()
{
    bool result = true;

    result &&= initialize();
    result &&= do_stuff();
    result &&= do_more_stuff();
    result &&= do_final_stuff();

    cleanup();
    return result;
}

If any of the functions fail, the functions after it won't be called.

On the other hand, I've often wanted to have a => operator.  "a => b"
would be equivalent to "!a || b". Using this instead of the usual 
"if (a) b;" tickles my linguistic nerves in the same fashion as the perl
idiom "<do something> or die;". But maybe such syntactical sugar doesn't
belong in a serious language. ;)

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction
to be used by nations other than the US.

edgein123 aol.com writes:

In article <slrnc2ncfv.76a.jsykari pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?=
says...
In article <c0fegm$2u05$1 digitaldaemon.com>, Matthias Becker wrote:
Why is there no &&= nor ||= ind D?

bool foo;

So something like this should be possible:
foo &&= bar();
  

I can't see that being used much.  All that extra work for the compiler 
writer for little gain.

 How often do you use %= ?

Occasionally. It's nice operator to have around when you want to modify
the index to a circular buffer and keep it in the valid range.

But I've never thought of using &&=, maybe simply because there isn't
one. And I've only seen &= used once or twice. Logically it makes sense,
though, since almost all other operators have an assignment equivalent.

And "&&=" would provide one way of handling errors and cleaning up
properly (if you don't want to use RAII or goto):

bool f()
{
    bool result = true;

    result &&= initialize();
    result &&= do_stuff();
    result &&= do_more_stuff();
    result &&= do_final_stuff();

    cleanup();
    return result;
}

If any of the functions fail, the functions after it won't be called.

On the other hand, I've often wanted to have a => operator.  "a => b"
would be equivalent to "!a || b". Using this instead of the usual 
"if (a) b;" tickles my linguistic nerves in the same fashion as the perl
idiom "<do something> or die;". But maybe such syntactical sugar doesn't
belong in a serious language. ;)

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction
to be used by nations other than the US.

I must agree that there is no need for a &&= or ||= operator. Furthermore, I
would also say that there shouldn't be a need for a && or || operator. Okay,
after saying that I bet everyone is wondering "is he an idiot? Obviously he has
no idea what he is talking about." So let me explain.

D provides operator overloading and as such should know that (uint) & (uint) is
not the same as (bool) & (bool). The reason why C and C++ have the && and ||
operator is because neither one has a true boolean type (in fact originally,
they didn't have one at all). Instead they define false to be zero, and true to
be everything else, thus the following code is legal:

int x;
int y;
/* do something */
if (x && (y > 0)) /* do something */

The && operator tells the compiler that the previous subexpression was a check
agaist zero. Arguably, code like this should be illegal. Yes, I'll admit I may
have used the implicit check against zero on several occassions myself, but it
really is less readable and maintainable. The language should enforce all
expressions within an if condition or loop condition to be of type Boolean. If
indeed we do enforce that, then that same code would be written as:

int x;
int y;
/* do something */
if ((x != 0) && (y > 0)) /* do something */

Here, there is no longer any ambiguity as to what the programmer intended. We
have a boolean and-ed with a boolean. Since boolean is built in, the compiler
should know to only execute the second part if the first part evaluates to true.

Now, what this doesn't let you do is to use the non short-circut condition that
is also available in C/C++. But lets be honest, how many times have you had the
nead to use it. I myself cannot say I've ever had the need to use it. In fact,
most people aren't even aware of it, and can also lead to more maintainability
problems. So for example the following two statements are legal in C and C++,
but are *not* equivalanet

if ( (x != 0) && fn() ) /* do something */
if ( (x != 0) & fn() ) /* do something */

In the first case, fn is called if and only if x != 0. In the second case, fn is
called regardless of the value of x! This is the type of mistake that can go
unnoticed by a the programmer or a code review, but hopefully a lint program
will catch. (If you don't know what lint is, I suggest you find and use it!
PC-Lint by Gimpel software is quite good: www.gimpel.com)

- Eric

Derek Parnell <Derek.Parnell No.Spam> writes:

On Thu, 12 Feb 2004 18:03:08 +0000 (UTC) (02/13/04 05:03:08)
, <edgein123 aol.com> wrote:

 In article <slrnc2ncfv.76a.jsykari pulu.hut.fi>, Antti 
 =?iso-8859-1?Q?Syk=E4ri?=

[snip]

 I must agree that there is no need for a &&= or ||= operator. 
 Furthermore, I
 would also say that there shouldn't be a need for a && or || operator. 
 Okay,
 after saying that I bet everyone is wondering "is he an idiot? Obviously 
 he has
 no idea what he is talking about." So let me explain.

 D provides operator overloading and as such should know that (uint) & 
 (uint) is
 not the same as (bool) & (bool). The reason why C and C++ have the && 
 and ||
 operator is because neither one has a true boolean type (in fact 
 originally,
 they didn't have one at all). Instead they define false to be zero, and 
 true to
 be everything else, thus the following code is legal:

 int x;
 int y;
 /* do something */
 if (x && (y > 0)) /* do something */

 The && operator tells the compiler that the previous subexpression was a 
 check
 agaist zero. Arguably, code like this should be illegal. Yes, I'll admit 
 I may
 have used the implicit check against zero on several occassions myself, 
 but it
 really is less readable and maintainable. The language should enforce all
 expressions within an if condition or loop condition to be of type 
 Boolean. If
 indeed we do enforce that, then that same code would be written as:

 int x;
 int y;
 /* do something */
 if ((x != 0) && (y > 0)) /* do something */

 Here, there is no longer any ambiguity as to what the programmer 
 intended. We
 have a boolean and-ed with a boolean. Since boolean is built in, the 
 compiler
 should know to only execute the second part if the first part evaluates 
 to true.

There is some merit in what you say. I like program code to be explict in 
showing the programmer's intentions.

 Now, what this doesn't let you do is to use the non short-circut 
 condition that
 is also available in C/C++. But lets be honest, how many times have you 
 had the
 nead to use it. I myself cannot say I've ever had the need to use it. In 
 fact,
 most people aren't even aware of it, and can also lead to more 
 maintainability
 problems. So for example the following two statements are legal in C and 
 C++,
 but are *not* equivalanet

 if ( (x != 0) && fn() ) /* do something */
 if ( (x != 0) & fn() ) /* do something */

 In the first case, fn is called if and only if x != 0. In the second 
 case, fn is
 called regardless of the value of x! This is the type of mistake that 
 can go
 unnoticed by a the programmer or a code review, but hopefully a lint 
 program
 will catch.

Actually, I rather use the short-circuit feature a lot. Especially in this 
sort of case ...

   if ( (index >= 0) && (index <= maxsize) && (myArray[index] = target))
   {
     /* do something */
   }
   else
   {
      /* Not an error, but just ignored. */
   }

-- 
Derek

edgein123 aol.com writes:

In article <opr291uej9yj5swd news.digitalmars.com>, Derek Parnell says...
On Thu, 12 Feb 2004 18:03:08 +0000 (UTC) (02/13/04 05:03:08)
, <edgein123 aol.com> wrote:

 In article <slrnc2ncfv.76a.jsykari pulu.hut.fi>, Antti 
 =?iso-8859-1?Q?Syk=E4ri?=

[snip]

 I must agree that there is no need for a &&= or ||= operator. 
 Furthermore, I
 would also say that there shouldn't be a need for a && or || operator. 
 Okay,
 after saying that I bet everyone is wondering "is he an idiot? Obviously 
 he has
 no idea what he is talking about." So let me explain.

 D provides operator overloading and as such should know that (uint) & 
 (uint) is
 not the same as (bool) & (bool). The reason why C and C++ have the && 
 and ||
 operator is because neither one has a true boolean type (in fact 
 originally,
 they didn't have one at all). Instead they define false to be zero, and 
 true to
 be everything else, thus the following code is legal:

 int x;
 int y;
 /* do something */
 if (x && (y > 0)) /* do something */

 The && operator tells the compiler that the previous subexpression was a 
 check
 agaist zero. Arguably, code like this should be illegal. Yes, I'll admit 
 I may
 have used the implicit check against zero on several occassions myself, 
 but it
 really is less readable and maintainable. The language should enforce all
 expressions within an if condition or loop condition to be of type 
 Boolean. If
 indeed we do enforce that, then that same code would be written as:

 int x;
 int y;
 /* do something */
 if ((x != 0) && (y > 0)) /* do something */

 Here, there is no longer any ambiguity as to what the programmer 
 intended. We
 have a boolean and-ed with a boolean. Since boolean is built in, the 
 compiler
 should know to only execute the second part if the first part evaluates 
 to true.

There is some merit in what you say. I like program code to be explict in 
showing the programmer's intentions.

 Now, what this doesn't let you do is to use the non short-circut 
 condition that
 is also available in C/C++. But lets be honest, how many times have you 
 had the
 nead to use it. I myself cannot say I've ever had the need to use it. In 
 fact,
 most people aren't even aware of it, and can also lead to more 
 maintainability
 problems. So for example the following two statements are legal in C and 
 C++,
 but are *not* equivalanet

 if ( (x != 0) && fn() ) /* do something */
 if ( (x != 0) & fn() ) /* do something */

 In the first case, fn is called if and only if x != 0. In the second 
 case, fn is
 called regardless of the value of x! This is the type of mistake that 
 can go
 unnoticed by a the programmer or a code review, but hopefully a lint 
 program
 will catch.

Actually, I rather use the short-circuit feature a lot. Especially in this 
sort of case ...

   if ( (index >= 0) && (index <= maxsize) && (myArray[index] = target))
   {
     /* do something */
   }
   else
   {
      /* Not an error, but just ignored. */
   }

-- 
Derek

My point was that programmers almost always use, and rely on, the short circuit
evaluation. I probably should been clearer that I meant most programmers do not
use the form "if ((expression1) & (expression2))." In fact it is hard to imagine
a case where you do NOT want short circuit evaluation, and for any such case
there is always a better way to code it. 

Hauke Duden <H.NS.Duden gmx.net> writes:

edgein123 aol.com wrote:
 In fact it is hard to imagine
 a case where you do NOT want short circuit evaluation, and for any such case
 there is always a better way to code it. 

Sweeping generalizations are always wrong!

Couldn't resist ;)

Hauke

Manfred Nowak <svv1999 hotmail.com> writes:

edgein123 wrote:

[...]
 In
 fact it is hard to imagine a case where you do NOT want short circuit
 evaluation, and for any such case there is always a better way to code
 it.

you are forgetting bit manipulations.

So long.

Matthias Becker <Matthias_member pathlink.com> writes:

Now, what this doesn't let you do is to use the non short-circut condition that
is also available in C/C++. But lets be honest, how many times have you had the
nead to use it. I myself cannot say I've ever had the need to use it. In fact,
most people aren't even aware of it, and can also lead to more maintainability
problems.

Ahh, don't say this. I use it all the time:

if (simpleTest || veryComplexTest)
..

eg:

if (string1 === string2 || str.cmp (string1, string2) == 0)
..

Eric Decker <Eric_member pathlink.com> writes:

In article <c0i2fo$123e$1 digitaldaemon.com>, Matthias Becker says...
Now, what this doesn't let you do is to use the non short-circut condition that
is also available in C/C++. But lets be honest, how many times have you had the
nead to use it. I myself cannot say I've ever had the need to use it. In fact,
most people aren't even aware of it, and can also lead to more maintainability
problems.

Ahh, don't say this. I use it all the time:

if (simpleTest || veryComplexTest)
..

eg:

if (string1 === string2 || str.cmp (string1, string2) == 0)
..

This is actually the point I was trying to make. People almost always use the
shortcircuit evaluation as you demonstrated in the above code. Rarely do you see
someone purposely do the following code, which can have very different results,
especially if the second expression involves an assigment or aa function call.
if (simpleTest | veryComplexText)
..

- Eric Decker

Matthias Becker <Matthias_member pathlink.com> writes:

if (string1 === string2 || str.cmp (string1, string2) == 0)
..

This is actually the point I was trying to make. People almost always use the
shortcircuit evaluation as you demonstrated in the above code. Rarely do you see
someone purposely do the following code, which can have very different results,
especially if the second expression involves an assigment or aa function call.
if (simpleTest | veryComplexText)

Of course, the expressions shouldn't have any sideeffects.
So you want to protect people that haven't learnd the basics of the language
they use from some errors?

J Anderson <REMOVEanderson badmama.com.au> writes:

Eric Decker wrote:

In article <c0i2fo$123e$1 digitaldaemon.com>, Matthias Becker says...
  

Now, what this doesn't let you do is to use the non short-circut condition that
is also available in C/C++. But lets be honest, how many times have you had the
nead to use it. I myself cannot say I've ever had the need to use it. In fact,
most people aren't even aware of it, and can also lead to more maintainability
problems.
      

Ahh, don't say this. I use it all the time:

if (simpleTest || veryComplexTest)
..

eg:

if (string1 === string2 || str.cmp (string1, string2) == 0)
..
    

This is actually the point I was trying to make. People almost always use the
shortcircuit evaluation as you demonstrated in the above code. Rarely do you see
someone purposely do the following code, which can have very different results,
especially if the second expression involves an assigment or aa function call.
if (simpleTest | veryComplexText)
...

- Eric Decker
  

I use the non-short-circuit version for logical binary operations. ie

const int flag1 = 1;
const int flag2 = 2;

if (flag & (flag1 | flag2)) //If flag1 and 2
...

-- 
-Anderson: http://badmama.com.au/~anderson/

"Matthew" <matthew.hat stlsoft.dot.org> writes:

<snip>

 I must agree that there is no need for a &&= or ||= operator. Furthermore,

I
 would also say that there shouldn't be a need for a && or || operator.

Okay,
 after saying that I bet everyone is wondering "is he an idiot? Obviously

he has
 no idea what he is talking about." So let me explain.

 D provides operator overloading and as such should know that (uint) &

(uint) is
 not the same as (bool) & (bool). The reason why C and C++ have the && and

||
 operator is because neither one has a true boolean type (in fact

originally,
 they didn't have one at all). Instead they define false to be zero, and

true to
 be everything else, thus the following code is legal:

 int x;
 int y;
 /* do something */
 if (x && (y > 0)) /* do something */

 The && operator tells the compiler that the previous subexpression was a

check
 agaist zero. Arguably, code like this should be illegal. Yes, I'll admit I

may
 have used the implicit check against zero on several occassions myself,

but it
 really is less readable and maintainable. The language should enforce all
 expressions within an if condition or loop condition to be of type

Boolean. If
 indeed we do enforce that, then that same code would be written as:

 int x;
 int y;
 /* do something */
 if ((x != 0) && (y > 0)) /* do something */

 Here, there is no longer any ambiguity as to what the programmer intended.

We
 have a boolean and-ed with a boolean. Since boolean is built in, the

compiler
 should know to only execute the second part if the first part evaluates to

true.

You had me with you down to this point, but then ...

 Now, what this doesn't let you do is to use the non short-circut condition

that
 is also available in C/C++. But lets be honest, how many times have you

had the
 nead to use it. I myself cannot say I've ever had the need to use it.

... you dropped the ball here.

I use short-circuit evaluation in C and C++ (and D) a lot, and it is a
highly useful and perfectly appropriate mechanism.

 In fact,
 most people aren't even aware of it, and can also lead to more

maintainability
 problems. So for example the following two statements are legal in C and

C++,
 but are *not* equivalanet

 if ( (x != 0) && fn() ) /* do something */
 if ( (x != 0) & fn() ) /* do something */

 In the first case, fn is called if and only if x != 0. In the second case,

fn is
 called regardless of the value of x! This is the type of mistake that can

go
 unnoticed by a the programmer or a code review, but hopefully a lint

program
 will catch. (If you don't know what lint is, I suggest you find and use

it!
 PC-Lint by Gimpel software is quite good: www.gimpel.com)

I would spot the second form in a code review less time than a bacterial
generation
decides to procreate. But then I'm nuts. ;)

Anyway, I completely agree that languages make a serious mistake in not
requiring all conditional (sub-)expressions be boolean. In fact, in my new
book - "Imperfect C++" (out in a few months' time) - there are two sections
on this issue.

Juan C <Juan_member pathlink.com> writes:

You'd better come up with a better example.

<snip>
bool f()
{
    bool result = true;

    result &&= initialize();
    result &&= do_stuff();
    result &&= do_more_stuff();
    result &&= do_final_stuff();

    cleanup();
    return result;
}

If any of the functions fail, the functions after it won't be called.

</snip>

I've used (when I was very young) something more like:

bool f()
{
bool result = true;

result = initialize() &&
do_stuff()        &&
do_more_stuff()   &&
do_final_stuff()  ;

cleanup();
return result;
}

or

bool f()
{
bool result = true;

if ( initialize()      &&
do_stuff()        &&
do_more_stuff()   &&
do_final_stuff() )
{
// Meat of the matter
}

cleanup();
return result;
}

but this is all poor style anyway as the cause of the problem is hidden.
And try/catch exception handling should be used instead:

bool f()
{
bool result = true ;

try
{
initialize() ; 
do_stuff() ;
do_more_stuff() ;
do_final_stuff() ;
}
catch ( ... ) 
{
// handle the exception
result = false ;
} 
finally
{
cleanup() ;
}

return result ;
}

"Matthew" <matthew.hat stlsoft.dot.org> writes:

<snip>

 bool f()
 {
     bool result = true;

     result &&= initialize();
     result &&= do_stuff();
     result &&= do_more_stuff();
     result &&= do_final_stuff();

     cleanup();
     return result;
 }

 If any of the functions fail, the functions after it won't be called.

This is horrid. But I use it on occasion, so I'll say no more .... ;)


 On the other hand, I've often wanted to have a => operator.  "a => b"
 would be equivalent to "!a || b".

yes, yes, yes, yes, yes, yes!!!

The good old bi-implication. Wonderful. Give me one of those, if you will.
:)

Using this instead of the usual
 "if (a) b;" tickles my linguistic nerves in the same fashion as the perl
 idiom "<do something> or die;". But maybe such syntactical sugar doesn't
 belong in a serious language. ;)

"Nam" <dreamweaver mail15.com> writes:

Sorry but I don't know clealy about &&=
Does it mean result= result AND do_stuff() ???
When all of them in string context or boolean , I can understand .
but if in string why don't just use + , and if in boolean I'm sorry but I
can't see any good point about this syntax.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c1c90k$6se$1 digitaldaemon.com...
 <snip>

 bool f()
 {
     bool result = true;

     result &&= initialize();
     result &&= do_stuff();
     result &&= do_more_stuff();
     result &&= do_final_stuff();

     cleanup();
     return result;
 }

 If any of the functions fail, the functions after it won't be called.

 This is horrid. But I use it on occasion, so I'll say no more .... ;)


 On the other hand, I've often wanted to have a => operator.  "a => b"
 would be equivalent to "!a || b".

 yes, yes, yes, yes, yes, yes!!!

 The good old bi-implication. Wonderful. Give me one of those, if you will.
 :)

Using this instead of the usual
 "if (a) b;" tickles my linguistic nerves in the same fashion as the perl
 idiom "<do something> or die;". But maybe such syntactical sugar doesn't
 belong in a serious language. ;)

Matthias Becker <Matthias_member pathlink.com> writes:

Sorry but I don't know clealy about &&=
Does it mean result= result AND do_stuff() ???

Of course, but don't forget the short cirquit behavior.

When all of them in string context or boolean , I can understand .
but if in string why don't just use + , and if in boolean I'm sorry but I
can't see any good point about this syntax.

???


foo &&= bar

means

foo = foo && bar;

so if foo is false foo simply stays falls. If foo is true bar is executed and
foo is set to it's result. That's all.