www.digitalmars.com         C & C++   DMDScript  

D - &&= and ||=

reply 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();
Feb 11 2004
parent reply 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/
Feb 11 2004
next sibling parent reply "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/
Feb 11 2004
parent 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.
Feb 12 2004
prev sibling parent reply 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 %= ?
Feb 12 2004
parent reply 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.
Feb 12 2004
next sibling parent reply 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
Feb 12 2004
next sibling parent reply 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
Feb 12 2004
parent reply 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.
Feb 12 2004
next sibling parent 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
Feb 12 2004
prev sibling parent 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.
Feb 12 2004
prev sibling next sibling parent reply 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) ..
Feb 13 2004
parent reply 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
Feb 13 2004
next sibling parent 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?
Feb 13 2004
prev sibling parent 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/
Feb 13 2004
prev sibling parent "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.
Feb 22 2004
prev sibling next sibling parent 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 ; }
Feb 12 2004
prev sibling parent reply "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. ;)
Feb 22 2004
parent reply "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. ;)
Mar 02 2004
parent 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.
Mar 02 2004