2

I see that java (and many other languages like C# and VB) provide short-circuit and non short-circuit versions of logical "and" and "or" operators. Where as C/C++ do not provide for non short-circuit versions.

When are these non short-circuit versions required? And if one can do without them why have these other languages provided for it?

chrylis -cautiouslyoptimistic-
  • 75,269
  • 21
  • 115
  • 152
John
  • 107
  • 6
  • Please provide an example code of what you are talking about. – OldProgrammer Feb 09 '14 at 01:41
  • check this http://stackoverflow.com/questions/9264897/reason-for-the-exsistance-of-non-short-circuit-logical-operators – Camilo Feb 09 '14 at 01:42
  • 1
    Actually, C and C++ do provide the operators your're talking about (that's where most of the other languages got them from). It's not really useful or correct to think of them as eager boolean logic operators though. –  Feb 09 '14 at 01:48
  • 1
    I would say, as per *my* code guidelines, *never* use `&` and `|` for logical conditions, but rather move the side-effects *out* of the expression .. – user2864740 Feb 09 '14 at 01:48
  • possible duplicate of [What are the cases in which it is better to use unconditional AND (& instead of &&)](http://stackoverflow.com/questions/11411907/what-are-the-cases-in-which-it-is-better-to-use-unconditional-and-instead-of) – Louis Wasserman Feb 09 '14 at 01:49

1 Answers1

3

For example, you might have a situation where your conditionals are calculated by two methods:

if (methodA() && methodB())

Now if you absolutely require that both methods be ran at this point (perhaps they do something else relevant, like mark down that they have been evaluated), then you should not short-circuit the call:

if (methodA() & methodB())

This guarantees the same result, but it also guarantees that both methods will run. In general it's almost never used in practice from what I've seen, and I would possibly argue that it's even bad practice.

As to the question of WHY is this functionality in some languages and not others - that's simply a question for the language designers. At best we could guess here what their intention was.

chrylis -cautiouslyoptimistic-
  • 75,269
  • 21
  • 115
  • 152
Kon
  • 10,702
  • 6
  • 41
  • 58
  • You mean then you should _not_. – Keppil Feb 09 '14 at 01:43
  • What do you mean? Did I miss a word somewhere? – Kon Feb 09 '14 at 01:43
  • Yeah, and I put it in instead of making a nonspecific comment. – chrylis -cautiouslyoptimistic- Feb 09 '14 at 01:45
  • I see, don't know how I missed it even after proof reading following @Keppil's comment. Thanks for the edit. – Kon Feb 09 '14 at 01:46
  • 1
    Because it's nearly impossible to proofread your own writing, since you already knew what you meant. ;-) – chrylis -cautiouslyoptimistic- Feb 09 '14 at 01:46
  • So you mean that while some languages provide for a non short-circuit version of these operator and they have a valid case when they could be used, it is not a good maintainable code to rather use them. The code should rather work around to use a short circuited version of the operator and call these methods prior to that short circuited if statement – so that the programmer intention is made explicitly clear. Just that some languages provide for writing such a code that can use these non short-circuited versions instead. – John Feb 09 '14 at 02:02
  • 1
    @John Yes, essentially if you require these two methods to run, then run them and assign their return value to some temporary flags. Then, when it's time to compare, just compare the flags themselves. This eliminates the need for non-short-circuit evaluation. If you have no other question you can mark this answer as accepted by clicking the check mark under my answer score. – Kon Feb 09 '14 at 02:06