Perché la condizione del punto di interruzione del debugger consente un'istruzione di assegnazione come condizione di bool?

Question

Questo è molto pericoloso, quindi mi chiedo perché è permesso. Dal momento che ho spesso bisogno di passare da VB.NET e C# a volte aggiungo breakpoint-condizioni come segue:

foo = "bah" 

Voglio smettere se la variabile stringfoo è "bah, quindi il modo corretto era di usare al posto di foo == "bah"foo = "bah".

Ma "funziona". Non si ricevono avvisi o errori in fase di compilazione o di runtime. Ma in realtà questo modifica la variabile foo, lo rende sempre "bah" anche se aveva un valore diverso. Poiché ciò accade silenziosamente (il punto di interruzione non viene mai colpito) è incredibilmente pericoloso.

Perché è consentito? Dov'è il mio errore nel ragionamento (a parte confondere la sintassi C# e VB.NET)? In C# (a differenza di VB.NET) un assignment statement restituisce il valore assegnato, quindi non un bool, ma un string in questo caso. Ma una condizione di punto di interruzione deve essere un bool se si seleziona la casella "È vero".

Ecco un piccolo "programma" del campione e screenshot dal mio (tedesco) IDE:

static void Main() 
{ 
    string foo = "foo"; 
    // breakpoint with assignment(foo = "bah") instead of comparison(foo == "bah"): 
    Console.WriteLine(foo); // bah, variable is changed from the breakpoint window 
} 

la finestra di breakpoint-condizione:

Il codice come immagine compreso il punto di interruzione :

Answer 1

È una conseguenza automatica della sintassi C#, comune nel gruppo di lingue delle parentesi graffe. Un incarico è anche un'espressione, il suo risultato è il valore dell'operando di destra. Il debugger non si oppone né alle espressioni che hanno effetti collaterali, né sarebbe semplice sopprimerle. Potrebbe essere incolpato di non controllare che l'espressione abbia un risultato bool, tuttavia il debugger non ha un parser in linguaggio C# completo. Questo potrebbe essere risolto in VS2015 grazie al progetto Roslyn. [Nota: vedi addendum in basso].

Anche il motivo principale per cui i linguaggi di parentesi graffa richiedono un operatore separato per l'uguaglianza, == vs =. Che di per sé deve essere responsabile di miliardi di dollari di bug, ogni programmatore C commette questo errore almeno una volta.

VB.NET è diverso, l'assegnazione è una dichiarazione e il token = è valido sia per l'assegnazione che per il confronto. Puoi dirlo dal debugger, invece seleziona l'operatore di uguaglianza e non modifica la variabile.

Tieni presente che questo è effettivamente utile. Ti consente di aggirare temporaneamente un bug, forzare il valore della variabile e permetterti di continuare il debug e concentrarti su un altro problema. O creare una condizione di test. È abbastanza utile. In una vita precedente, ho scritto un compilatore e un debugger e ho implementato "trace points". Scoperto per caso lo stesso scenario e lasciato in posizione. Funzionava in un host che si basava molto sulle macchine a stati, ignorando la variabile di stato mentre il debugging era incredibilmente utile.L'incidente, no, non così utile :)

---

Una nota su ciò che gli altri così gli utenti stanno osservando, dipende dal motore di debug che si utilizza. L'opzione rilevante in VS2013 è Strumenti + Opzioni, Debug, Generale, "Usa modalità di compatibilità gestita". La stessa opzione esiste in VS2012, aveva un nome leggermente diverso (non ricordo). Quando spuntato, si ottiene un motore di debug più vecchio, uno ancora compatibile con C++/CLI. Lo stesso usato in VS2010.

Quindi questa è una soluzione alternativa per VS2013, deselezionare l'opzione per ottenere che il debugger verifichi che l'espressione produca un risultato bool. Ottieni un po 'più chic con quel nuovo motore di debug, come vedere i valori restituiti dal metodo e il supporto Modifica + Continua per i processi a 64 bit.

Answer 2

Non posso essere d'accordo sulla natura bug di questo comportamento. Pochi esempi in cui per scopi di debug nella mia vita se fosse utile:
1. Altri thread modifica qualcosa nel codice.
2. Altre servizio valore aggiornato in dB
quindi suppongo che per i casi di sincronizzazione può essere caratteristica utile, ma sono d'accordo che può causare problemi