AND &&

Ostatnio wyczytałem, że kolejność czynników w iloczynie logicznym w Javie ma znaczenie.Ma ktoś jakieś wiadomości na ten temat?
Chodzi konkretnie, że wyr1 && wyr2 i wyr2 && wyr1 to nie zawsze to samo.W google to na pewno tego nie znajde.

Zaóżmy, że funkcja f(..) zwróci false, a funkcja g(...) zwróci true

if(f(...) && g(...)) // g(...) się nie wykona
if(g(...) && f(...)) // wykonają się obie funkcje

Jeśli te funkcje zmieniają stan jakiegoś obiektu, to jest duża różnica.
Inny przykład:

if(w1 && w2)

Jeżeli warunek w1 na ogól zachodzi (lub jego sprawdzanie jest czasochłonne), to lepiej sprawdzać

if(w2 && w1)

Bardziej obrazowo to co bogdans powiedział:

publiv void f()
Object o = null;
// przechodzi
if(o!=null && o.toString()!=null){
   out.println(o);
}
// nie przechodzi, NPE
if(o.toString()!=null && o!=null){
   out.println(o);
}

Dzięki :-)

A wyjasniajac dokladnie o co chodzi: operacje logiczne w Java wykonuja sie od lewej strony do prawej (z zachowaniem priorytetow operatorow, tj. && ma wiekszy priorytet niz ||). Z prostej logiki tych operatorow wynika, ze:

• koniunkcja (AND) jest prawdziwa wtedy i tylko wtedy, gdy oba wyrazenia sa prawdziwe
• alternatywa (OR) jest falszywa wtedy i tylko wtedy, gdy oba wyrazenia sa falszywe

A zatem, po dokonaniu prostych optymalizacji wynikajacych z powyzszego:

• && - jesli pierwsze (lewe) wyrazenie jest falszywe, nie ma sensu sprawdzac drugiego, bo i tak rezultatem jest falsz
• || - jesli pierwsze (lewe) wyrazenie jest prawdziwe, nie ma potrzeby sprawdzac drugiego, bo i tak rezultatem jest prawda

Takie podejscie przyspiesza obliczenia, ale moze powodowac trudne do odnalezienia bledy czasu uruchomienia (runtime errors).

ws napisał(a)

Takie podejscie przyspiesza obliczenia, ale moze powodowac trudne do odnalezienia bledy czasu uruchomienia (runtime errors).
Jeśli wystąpienie nulla jest spodziewane, to sprawdzasz.. Jeśli nie jest, to nie sprawdzasz, dostaniesz NPE i będziesz wiedział gdzie jest problem.

Keraj napisał(a)

ws napisał(a)

Takie podejscie przyspiesza obliczenia, ale moze powodowac trudne do odnalezienia bledy czasu uruchomienia (runtime errors).

Jeśli wystąpienie nulla jest spodziewane, to sprawdzasz...

Zgadza sie. Nawet testy jednostkowe, podczas tworzenia systemu, moga wykazac takie zachowanie. Ale testy nie symuluja pracy calego systemu.

Keraj napisał(a)

... Jeśli nie jest, to nie sprawdzasz, dostaniesz NPE i będziesz wiedział gdzie jest problem.

Co, jesli taki krytyczny blok kodu wywoluje sie bardzo rzadko? Np. pol roku po wdrozeniu systemu na 200-300 tys. linii kodu? Wszystko trzeba przewidziec, ale nie wszystko od razu sie da.

Poza tym, NPE to chyba najlepszy, z punktu widzenia programisty, blad, ktory moglby wystapic. A jesli to bylaby modyfikacja licznika (zmienna typu prostego) lub wywoalnie metody modyfikujacej stan innego obiektu?

Priorytety operatorow i kolejnosc wykonywania operacji czesto powoduja bledy w programach poczatkujacych programistow, ale to nie znaczy, IMO, ze bardziej doswiadczeni koderzy moga to bagatelizowac.