Quando la valutazione del cortocircuito è negativa?

Alcuni termini in un'espressione logica possono avere effetti collaterali. A volte è necessario assicurarsi che tutti gli effetti collaterali avvengano nell'ordine indicato, e nessuno viene saltato ed è il risultato della valutazione che guida la logica:

if not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

In altri casi, non si desidera valutare nessuno dei termini rimanenti se una valutazione precedente restituisce false.

if IsAirborne() and not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

Alcuni hanno sostenuto che fare affidamento sul comportamento di cortocircuito nel secondo esempio è una cattiva forma, ma questo sta entrando nello stile di codifica e nei sistemi di credenze. Ci sono molti ottimi bit di codice nel mondo che si basano su quasi tutte le funzionalità offerte da un linguaggio, e questo è proprio così.

ANDALSO di VB è nitido e sembra essere un tentativo di rendere la pratica più accettabile.

Come sottolinea JimmyJames nella sua risposta, ci possono essere implicazioni di prestazioni misurabili sulla valutazione del cortocircuito. Linguaggi che non forniscono il meccanismo, valutano sempre ogni termine dell'espressione, mentre quelli che lo forniscono possono generare dichiarazioni di ramo extra. In entrambi i casi, molto dipende dal numero di fasi di elaborazione richieste per valutare ciascuno dei termini e anche dalle architetture del compilatore e della CPU. Normalmente non ti interessano queste cose finché non hai un collo di bottiglia misurato nel codice e hai bisogno di capire come alleviarle. Qualsiasi regola "fai o non fai" per consentire la valutazione del cortocircuito nel tuo codice potrebbe avere la stessa probabilità di causare codice più lento e l'ottimizzazione anticipata può essere una perdita totale di tempo, quindi misura sempre, quindi ottimizza.

A quanto pare, la tua domanda non riguarda il cortocircuito in generale, ma il motivo per cui VB.NET fornisce agli operatori con e senza di esso. Con questo in mente, la risposta a

when is short-circuit evaluation bad?

è semplicemente: quando viola la retrocompatibilità .

Ok, ora puoi dire che VB.NET non è molto compatibile con i vecchi VB6 o VBA, tuttavia almeno alcune parti della lingua lo sono. La decisione di Microsoft di mantenere la vecchia semantica AND e OR (senza cortocircuiti) ha creato un'enorme categoria di errori con meno probabilità di verificarsi quando si eseguono il porting di vecchi programmi VB su VB.NET.

D'altra parte, i progettisti di linguaggio VB.NET hanno probabilmente condiviso la tua opinione sul fatto che il cortocircuito sia una buona cosa. Quando ricordo bene, le prime versioni di pre-release di VB.NET fornivano agli operatori AND o OR un cortocircuito, ma il feedback degli sviluppatori doveva essere stato così male che MS ritirò questa decisione prima che apparisse VB.NET 1.0. Pertanto, i progettisti hanno deciso di implementarlo in termini di nuove parole chiave ANDALSO e ORELSE come compromesso tra retrocompatibilità e utilità.

IMHO questa è stata una buona decisione. Negli ultimi dieci anni ho dovuto eseguire il porting di diversi programmi precedenti e non dover effettuare un'analisi di impatto pesante per ogni espressione logica tra cui AND e / o OR (pun intended) ha reso questo compito molto più semplice ed economico. D'altra parte, ogni volta che devo scrivere una nuova espressione logica in VB.NET, la mia scelta di default per gli operatori sono le forme di cortocircuito, cioè quello a cui sono abituato da C, C ++, C # etc e che consente Io scrivo diversi idiomi in forma più concisa (anche se ANDALSO ha bisogno di 4 caratteri in più per scrivere).

Se non sei convinto, ti consiglio di leggere il fantastico articolo di Joel Spolsky su cuffie marziane , sul perché le prime decisioni di progettazione nello sviluppo del software non possono essere facilmente revocate dopo che il componente o la lingua o l'API in gioco hanno raggiunto una base di utenti di una certa dimensione.

when is short-circut evaluation bad?

Diventano cattivi , non appena inizi a fare affidamento sugli effetti collaterali delle espressioni che ti aspetti di eseguire nella valutazione di un risultato globale booleano.

Avvertenza : questo è un po 'esoterico in quanto in quasi tutti i casi, gli sviluppatori non dovrebbero preoccuparsene. Ma ... ci può essere un successo nelle prestazioni a causa della valutazione condizionale in quanto crea ramificazione in esecuzione. Un'operazione senza cortocircuito non si dirama ed è più prevedibile.

Il motivo per cui questo raramente conta è che il costo è in genere piccolo e solitamente superato di solito dal costo della valutazione della seconda (o terza, ecc.) condizione. Ciò sarà sempre importante nelle routine computazionalmente costose quando sono richieste prestazioni elevate e potrebbe anche non esserlo.

Pascal non ha definito se AND e OR utilizzino o meno la valutazione del cortocircuito, fornendo il peggiore dei due mondi.

C e C ++ hanno operazioni bit a bit & e | che in pratica ti danno operazioni non a corto circuito. E i compilatori sono liberi di valutare come preferiscono se non fa una differenza osservabile.