rækkefølge af udtryk med brug af &&operatoren

Udtrykket evalueres altid fra venstre til højre - med mindre at der bruges paranteser til at ændre rækkefølgen.

Hvis i>0 leddet *ikke* er sandt, så blver det næste led slet ikke forsøgt udregnet.

og det er ALTID fra venstre mod højre?

Så vidt jeg husker(er ikke helt sikker) kræver gcc compileren at alle udtryk er lovlige, fordi den, hvis optimering er slået til, kan finde på at bytte om på rækkefølgen, således at
udtrykket evaluers som

if(100/i == 20 && i > 0)

//Funtex

Hvorvidt det går godt i den forstand at det "giver dig det ønskede resultat", er imidlertid usikkert.

Det afhænger f.eks. ag om i er en integer eller en float. Hvis i er en integervariabel så vil 100/i nemlig være en heltalsdivision. Dette har f.eks. den konsekvens at.

i = 13 => 100/i = 7
i = 42 => 100/i = 2
i = 50 => 100/i = 2
i = 1000 => 100/i = 0

(alt lig med eller over 101 vil resulterer i 0).

Fra Microsoft selv:

http://msdn2.microsoft.com/en-US/library/2a723cdk.aspx

"
The operation

x && y

corresponds to the operation

x & y

except that if x is false, y is not evaluated (because the result of the AND operation is false no matter what the value of y may be). This is known as "short-circuit" evaluation.
"

det er klart.
spørgsmålet handler udelukkende om rækkefølgen.
Det konkrete  kode jeg mistænker for fejl ser ca sådan ud:

try
{
  if(myObj != null && myObj.myFunc() == true)
  {

  }
}
catch(Exception e)
{
}
Jeg har en mistanke om at fejlen skyldes kald af myFunc() selvom byObj == null.
Men hvis rækkefølgen ALTID er fra venstre mod højre, uanset optimering kan det jo ikke forklar fejlen.

//Funtex

Den if-sætning ser sund nok ud, men hvis du vil være elet 101% sikker på at det ikke er det fejlen skydles, kan du jo bryde den op i det ækvivalente udtryk:

try
{
    if (myObj != null)
    {
        if (myObj.myFunc() == true)
        {
        }
    }
}
catch(Exception e)
{
}

(jeg forudsiger dog at du får den sammen fejl ;^))

Ja det er naturligvis muligt at dele den op.
Fejlen er aperiodisk og bla derfor svær at reproducere. Derfor vil jeg nødigt ændre i koden før jeg er rimelig sikker på hvor fejlen ligger.
Jeg har kigget lidt i specifikationen for C# men jeg synes ikke det fremgår helt klart om række følgen altid er fra venstre mod højre under evalueringen.

MSDNs beskrivelse, som du også linker til tyder dog på at det altid er samme evaluerings rækkefølge

//Funtex

Jeg synes at nielle's link til MSDN klart siger, at der altid evalueres fra venstre mod højre. Det understøttes af C# specifikationen, der bl.a. siger:

•    The operation x && y corresponds to the operation x & y, except that y is evaluated only if x is true.

-- og --

•    The operation x && y is evaluated as x ? y : false. In other words, x is first evaluated and converted to type bool. Then, if x is true, y is evaluated and converted to type bool, and this becomes the result of the operation. Otherwise, the result of the operation is false.

(page 169).

Jeg er nu også helt sikker. Jeg gav kun kode-eksemplet for at du selv kunne konstatere at fejlen alligevel opstod, og at den derfor ikke havde noget at gøre med &&.

Fint

Post et svar og du får points :)

//Funtex

Svar :^)