[C] Valutazione condizioni

[GByTe87]

Buongiorno a tutti :)

Avrei un quesito: le istruzioni che io utilizzo come condizioni, per esempio per un if, vengono eseguite sempre tutte?

Temo di essere stato criptico: ho un codice del genere:

if ((struct_1.index > -1) && (struct_2[struct_1.index].description != NULL)) {
doSomething();
}

Mettiamo, per esempio, che struct_1.index valga -1: la seconda parte della condizione (con relativo uso di un indice negativo per accedere a un array e conseguente sigsegv :fagiano:) viene valutata?

Se può servire, compilo con GCC :)
Grazie :D

[Unrue]

No, nel caso in esempio, essendoci un AND, se la prima condizione è falsa lo è anche l'AND, quindi la seconda non viene eseguita.

Non ricordo però se questo vale sempre o solo quando compili con ottimizzazioni :stordita:

Con un OR è diverso, devono essere valutate per forza di cose entrambe, con o senza ottimizzazioni. Quindi dipende sia dalla tabella di verità dell'operatore sia dalle ottimizzazioni

[GByTe87]

No, nel caso in esempio, essendoci un AND, se la prima condizione è falsa lo è anche l'AND, quindi la seconda non viene eseguita.

Mmm, perfetto, immaginavo fosse così :)

Grazie per la risposta rapida :p

Edit: infatti, ora vorrei capire se dipende dalle opzioni di ottimizzazione del compilatore... non vorrei avere un codice che si comporta in modo diverso in debug e in produzione... almeno, non più del solito :mc: :D

[Unrue]

Mmm, perfetto, immaginavo fosse così :)

Grazie per la risposta rapida :p

Edit: infatti, ora vorrei capire se dipende dalle opzioni di ottimizzazione del compilatore... non vorrei avere un codice che si comporta in modo diverso in debug e in produzione... almeno, non più del solito :mc: :D

Ripensandoci, secondo me dipende dalle ottimizzazioni. Se gli dici di non farle con -O0, non deve ottimizzare 'if, quindi fa il check su entrambe le condizioni. Anche perché, in modalità debug, supponi che ci sia un errore nella seconda condizione, se la salta non rilevo l'errore..

[wingman87]

Con un OR è diverso, devono essere valutate per forza di cose entrambe, con o senza ottimizzazioni. Quindi dipende sia dalla tabella di verità dell'operatore sia dalle ottimizzazioni
Mi sembra che con OR se la prima espressione è vera la seconda non viene valutata.

[GByTe87]

Mi sembra che con OR se la prima espressione è vera la seconda non viene valutata.

In effetti sarebbe anche logico, in questo caso :)

[banryu79]

Che io sappia nel linguagio C gli operatori logici booleani && e || sono "corto-circuitati" sempre, nel senso che sono tali proprio a livello semantico, quindi le opzioni di ottimizzazione del compilatore non c'entrano: ma magari mi ricordo male, qualcuno può confermare?

[fero86]

Mi sembra che con OR se la prima espressione è vera la seconda non viene valutata. esatto, si chiama lazy OR e fa parte della specifica del linguaggio. esiste anche il lazy AND: se il primo operando dell'operatore && risulta nullo il secondo non viene valutato e l'espressione restituisce direttamente un valore nullo.

[Unrue]

esatto, si chiama lazy OR e fa parte della specifica del linguaggio. esiste anche il lazy AND: se il primo operando dell'operatore && risulta nullo il secondo non viene valutato e l'espressione restituisce direttamente un valore nullo.

Questa non la sapevo, si impara sempre qualcosa :)

Però secondo me in fase di debug non viene fatta, altrimenti per l'esempio postato prima, se nella seconda condizione ho un errore interno, lo salterei in quanto non viene valutata.

[WarDuck]

No, nel caso in esempio, essendoci un AND, se la prima condizione è falsa lo è anche l'AND, quindi la seconda non viene eseguita.

Non ricordo però se questo vale sempre o solo quando compili con ottimizzazioni :stordita:

Con un OR è diverso, devono essere valutate per forza di cose entrambe, con o senza ottimizzazioni. Quindi dipende sia dalla tabella di verità dell'operatore sia dalle ottimizzazioni

Con l'OR se la prima è verificata non c'è bisogno di vedere la seconda.

Con l'AND se la prima NON è verificata non c'è bisogno di vedere la seconda espressione.

Ovviamente sono arrivato in ritardo :D.

[Unrue]

Con l'OR se la prima è verificata non c'è bisogno di vedere la seconda.



Si, infatti ho corretto :D

[gugoXX]

Si, confermo che in C, C++ e anche C# la valutazione degli operando && e || e' lazy.
Utile quindi nei confronti con NULL per i puntatori


if ((p!=null) && (p->campo!="valore"))
etc.

Il C, su tutti i compilatori, assicura che se la prima parte e' falsa, allora la seconda non viene neppure valutata. Che e' bene, altrimenti ci sarebbe un erroraccio a runtime

Questo e' quindi anche un ottimo motivo per non inserire codice "attivo" nelle valutazioni. Es se qualcuno scrive qualcosa come segue, spezziamo le braccine

if ((a==-4) && (++c == 6) && (bs!="goofy"))
{
// qualcosa
}

Perche' e' facile che possa essere scappato che talvolta c viene incrementata, e talvolta no. Direi che quando la si legge invece che pensare ad una ottimizzazione (poco necessaria) e' molto piu' probabile un bel baco.

Da anche a maggior ragione bene a mente nei linguaggi come C# dove e' possibile scrivere del codice attivo anche in un semplice get di una proprieta',
la cui lettura parrebbe quindi innocente, ma che potrebbe dare problemi analoghi come il precedente.



E se invece scrivessi cosi', cosa accadrebbe?


if ((struct_1.index > -1) & (struct_2[struct_1.index].description != NULL)) {
doSomething();
}

[fero86]

E se invece scrivessi cosi', cosa accadrebbe? che le valuta entrambe perché l'AND é bitwise.