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

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.

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

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

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

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/

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

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

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

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