Het verschil tussen & en && (| en II) in een voorbeeld

[Clemens Schalkw]

Ik heb gezocht naar het verschil tussen de operatoren & en && en | en ||.
Ik heb dit gevonden:

De conditionele operatoren && en || hebben dezelfde werking als de booleanse operatoren & en |, met het verschil dat de conditionele operatoren al stoppen met de evaluatie wanneer de linker operand een false oplevert. De rechter operand wordt dan nooit getest.

Hoe leg ik dit uit aan de hand van een voorbeeld?
Als ik bijvoorbeeld onderstaande doe:

    if (int a == 4 && int b == 8)

of

    if (int a == 4 & int b == 8)

 

[aaajeetee]

Bij de dubbele operatoren, stopt je if-statement al zodra de expressie "a == 4" FALSE oplevert.

Bij de enkele operatoren, gaat je if-statement ook nog de rest nalopen.


Bij je voorbeeld: 1e voorbeeld (dubbele) stopt dus al zodra a niet gelijk is aan 4. Het 2e voorbeeld gaat dan ook nog de "b == 8" evalueren.

 

[Clemens Schalkw]

Ja ok, dat snap ik. Maar ik zie het nut niet.
Als ik wil dat a == 4 EN b == 8.
Dan moeten ze toch allebei voldoen, anders heeft die hele if toch geen zin?
Of is dit gewoon een verkeerd voorbeeld?

 

[JP Romijn]

Je kunt in een if statement ook variabelen gebruiken/wijzigen. Het is dan dus van belang dat alle delen van de statement worden doorlopen.

 

[Clemens Schalkw]

zou je dit kunnen illustreren met een voorbeeld.
Ik snap wel wat je zegt, maar begrijp het nut er niet van.
Als ik (bijvoorbeeld) in een if() zeg dat als a == 4 & (dus 1 operator) b == 8.
Dan moet hij toch alsnog niet de code uitvoeren tussen { en }.
Of er nou 1 of beide niet voldoen aan de vergelijking?
Dus als a == 4 niet klopt, zou hij in beide gevallen het statement niet uit moeten voeren, evenals bij het niet kloppen van b == 8.
Toch??? :S

Ik waardeer jullie reakties enorm, maar ik ben er nog niet uit

 

[Supersnail]

if (functie1() && functie2())
{
  //do iets
}

"functie1" en "functie2" leveren een boolean waarde op, maar ze passen ook allebei bijv. een (globale) variabele aan. In dat geval wil je dat beide functies worden uitgevoerd. Ook als "functie1" al false oplevert.

 

[Clemens Schalkw]

Ok.
Dus dan worden de functies uitgevoerd, maar // doe iets doet dan niks als het goed is, toch?

 

[aaajeetee]

Ok.
Dus dan worden de functies uitgevoerd, maar // doe iets doet dan niks als het goed is, toch?

Of de if-statement in wordt gegaan is afhankelijk van de waardes uit de expressies.
Bijvoorbeeld:
false && false geeft hetzelfde resultaat als false & false. Beide expressies moeten dus wel true opleveren, om de code uit te voeren.

Het verschil in && en & zit 'm dus in wat Supersnail (en iedereen eigenlijk) zegt: bij & wordt de volgende expressie ook meegenomen.

 

[Clemens Schalkw]

ok. Bedankt voor de informatie.
Het is me wel duidelijk, ik denk dat ik een keer een goed praktijkvoorbeeld moet zien om het nut ervan te bepalen .

 

[keej]

Mss toch nog even verduidelijken dus

Wat er in het begin stond is eigenlijk niet juist voor ||.

De eerste link in google gaf al resultaat.

http://www.cafeaulait.org/course/week2/46.html

Bij && wordt begonnen met het eerste deel.
Als dat eerste deel "false" dan zal onafhankelijk van de waarde van het tweede deel het geheel false zijn. In dat geval moet het tweede deel niet meer gecontroleerd worden. Bij && gebeurt dat dan ook niet, bij & gebeurt dat wel altijd.

Bij || is het analoog. Als het eerste deel "true" is dan zal het geheel altijd "true" zijn en in dat geval hoeft het tweede deel niet meer nagegaan worden. Bij | worden wel altijd beide delen gecontroleerd.

Twee voordelen van && en ||: sneller (in sommige gevallen) en soms is het zo dat indien de voorwaarde voldaan is zodat het tweede deel niet meer gecontroleerd moet worden, dit tweede deel (al dan niet altijd) een foutmelding zou kunnen geven moest het toch uitgevoerd worden (hiervoor zou je een specifiek voorbeeld moeten zien, zie google-link).

De enige reden dat ik kan verzinnen om & en | te gebruiken is om testredenen bijvoorbeeld als je wil zien of het programma soms crasht bij gebruik van & en |; of bijvoorbeeld om de worst-case-snelheid van een algoritme na te gaan.