[Java] evalueren van een if-statement

[Marc]

Ik ben enigszins verbaast over de manier waarop Java een if-statement evalueert, en ik hoop dat iemand mij kan vertellen waarom Java het op deze manier doet. Neem bijvoorbeeld de volgende code (i is een globale variable):

Java: example1

int i = 0;
if (change() && (i == 5))
   System.out.println("yah");

...

private boolean change() {
   i = 5;
   return true;
}

Dit zal nooit "yah" printen, terwijl ik hier eigenlijk wel op hoopte. Ik verwachtte namelijk dat Java eerst de eerste conjunct volledig evalueert, en afhankelijk van het resultaat daarvan de tweede (wanneer de eerste faalt kan de tweede namelijk genegeerd worden), maar nu krijg ik het idee dat ze beiden tegelijk ge-evalueert worden.

[Verwijderd]

Gebeurt dit ook als je de haakjes rond (i == 5) weghaald? Ik vermoed dat die een hogere prioriteit krijgt door de haakjes.

[OrbitZ]

Java:

public class Test {
    static int i = 0; 
    public static void main(String[] args) {
        if (change() && (i == 5))
           System.out.println("yah"); 
    }
    
    private static boolean change() { 
        i = 5; 
        return true; 
    }
}

= yah

Java:

public class Test {
    static int i = 0; 
    public static void main(String[] args) {
        if ((i == 5) && change()) 
           System.out.println("yah"); 
    }
    
    private static boolean change() { 
        i = 5; 
        return true; 
    }
}

= niks

De code in if statements worden van links naar rechts geëvalueerd.

[Marc]

Je hebt gelijk Orbitz, maar het verschil zit hem hierin:

Java:

public class T { 
    static int i;  
    public static void main(String[] args) { 
        i = 0;
        if ((i == 5) && change())  
           System.out.println("yah");  
    } 
     
    private static boolean change() {  
        i = 5;  
        return true;  
    } 
}

Nu geeft hij geen "yah"... gek toch?

[CoolGamer]

Hij kijkt eerst aan de linker kant van &&, daarna pas aan de rechter kant als de linker kant waar is. Dus als je i op 0 zet, dan levert de linker kant false op. De rechterkant wordt dan niet eens meer uitgevoerd.

[alex3305]

Marc schreef op dinsdag 05 juni 2012 @ 22:42:
Je hebt gelijk Orbitz, maar het verschil zit hem hierin:

[...]

Nu geeft hij geen "yah"... gek toch?

Nee,

OrbitZ schreef op dinsdag 05 juni 2012 @ 22:38:
De code in if statements worden van links naar rechts geëvalueerd.

En i is daar niet gelijk aan vijf.

[RobIII]

Marc schreef op dinsdag 05 juni 2012 @ 22:42:
gek toch?

Hoezo is dat gek? Je hebt hier met 2 zaken te maken: scope en short circuiting.

Met alle respect, maar als je de basis niet goed begrijpt zou ik 't voortaan eerst even bij mezelf zoeken in plaats van Java (of eender welke taal) de schuld te geven Dit soort zaken zijn écht wel uitgekristalliseerd na jaren en miljoenen gebruikers

[edit]
Ondertussen spuit 11

[ Voor 54% gewijzigd door RobIII op 05-06-2012 22:49 ]

[Ozzie]

Het voorbeeld in je startpost zou gewoon in de if moeten komen hoor.

Java:

    private int i = 0;

    public Test() {
        if (change() && (i == 5)) {
            System.out.println("Bla");
        }
    }

    public boolean change() {
        i = 5;
        return true;
    }

Dit geeft bij mij gewoon 'Bla' in de sys.out

/edit volgende keer eerst kijken of er nog geen antwoorden zijn gegeven

[ Voor 11% gewijzigd door Ozzie op 05-06-2012 22:52 ]

[RobIII]

Ozzie schreef op dinsdag 05 juni 2012 @ 22:51:
Dit geeft bij mij gewoon 'Bla' in de sys.out

Wat aangeeft dat in z'n startpost een scope probleem aanwezig is (of: moet zijn). En wanneer 'ie dat fixed draait 'ie stiekem in z'n tweede post de condities om

[ Voor 9% gewijzigd door RobIII op 05-06-2012 22:54 ]

[Kajel]

Mocht je overigens willen dat wel beide operands geëvalueerd worden, dan kun je "&" gebruiken in het geval van AND en "|" in het geval van OR. Dit is uiteraard minder efficient.

[.oisyn]

RobIII schreef op dinsdag 05 juni 2012 @ 22:47:
en short circuiting

Ik zie niet helemaal hoe short-circuiting hier relevant is eigenlijk. Ook zonder short-circuit (door gebruik van een & ipv een && bijvoorbeeld) zal het resultaat gelijk zijn, want de expressies worden nou eenmaal van links naar rechts geëvalueerd.

[roy-t]

Sowieso wil ik nog even opmerkingen dat if statements die de state van je programma veranderen echt uit den bozen zijn en een grote bron van moeilijk vindbare bugs. Dit concept heeft ook wel side-effects en is een anti-pattern.

Wikipedia: Side effect (computer science)

[.oisyn]

Sorry maar dat vind ik echt nergens op slaan.

code:

if (ChangeSomething())
    Succeeded();
else
    Failed();

Uit den boze dus?

[Caelorum]

Je zou er het volgende van kunnen maken:

code:

bool success = ChangeSomething());

if (success)
    doe iets
else
    doe iets anders

Maar of dat nou veel beter is?

[ Voor 10% gewijzigd door Caelorum op 06-06-2012 15:01 ]

[NMe]

Dan is het nog steeds een if-statement dat de state van je programma verandert, dus dat is nou niet echt een schokkende wijziging behalve dat het meer code oplevert en lastiger leest.

Overigens ben ik het met .oisyn eens dat het een beetje onzin is dat een if-statement de state van je programma niet zou moeten kunnen aanpassen. Hoe wou je anders je programma in een andere state brengen op basis van condities?

[Janoz]

Toch vind ik dat Roy-t een punt heeft, maar dan wel wat specifieker. State veranderende expressies is geen probleem, maar state die veranderd halverwege de evaluatie is wel gevaarlijker. In die gevallen moet je het achterwege laten, of moet het duidelijk door de naamgeving van de gebruikte methodes zijn. Je moet de werking van een stuk code simpel kunnen doorgronden zonder elke methode in te stappen. In dit geval is niet te zien dat change de globale variabele i aan gaat passen en ziet de code er dus eigenlijk ook heel onlogisch uit.

[.oisyn]

Daar ben ik het ook mee eens, maar ongenuanceerde opmerkingen fakkel ik gewoon af

[voodooless]

Ik denk dat dit het wel illustratiever maakt:

Java:

public class Blaat {

    private static boolean bounce = false;

    public static final void main(String[] args) {

        if (blaat() && blaat()) {
            System.out.println("blaat");
        } else {
            System.out.println("kaas");
        }
    }

    private static boolean blaat() {
        boolean ret;
        if (!bounce) {
            bounce = true;
            ret = bounce;
        } else {
            ret = false;
        }
        System.out.println("ret: " + ret);
        return ret;
    }
}

't zal vast wel ergens toepassingen vinden, maar maakt het niet eenvoudig om dergelijke code te lezen of begrijpen.