Ciao e bentornato.
In questa lezione, vorrei dare una dimostrazione di come si può usare il debugger.
Vorrei quindi illustrarvi l'interfaccia grafica, mostrarvi come si può avviare un programma in modalità di debug, come si possono
impostare i punti di interruzione, come si può guardare lo stack delle chiamate e come si possono visualizzare diverse variabili utilizzando
la finestra di osservazione.
Un semplice programma che determina una media.
Userò questo come dimostrazione.
Tutto ciò che fa è leggere tre numeri interi, memorizzarli e poi calcolarne la media.
Prima di utilizzare il debugger, è necessario assicurarsi che la configurazione
sia impostata correttamente.
Ne ho già parlato in un video precedente, configurando sostanzialmente Code Light per l'uso del debugger.
Ma per rinfrescare la memoria, potete selezionare il progetto qui, fare clic con il pulsante destro del mouse e andare alle
impostazioni.
A seconda della piattaforma su cui ci si trova, bisogna assicurarsi che le impostazioni
del debugger qui a sinistra abbiano il giusto percorso per GDB.
Ora, se siete su Windows, questo può comportare l'uso di GDB X da Cygwin o l'uso di MinGW w64, qualunque sia il funzionamento.
Se si utilizza Unix e Linux, questo percorso non deve essere necessariamente impostato.
L'altra cosa importante è che nelle opzioni del compilatore ci si assicuri di compilare
per il debug, in modo che Dash G nano sia su dash o per l'ottimizzazione.
Ancora una volta, in Windows, queste cose devono essere impostate per avere informazioni di debug insieme
all'eseguibile.
Bisogna anche assicurarsi che si stia costruendo per la modalità di debug.
Quindi bisogna assicurarsi che sia selezionato debug e non release.
Una volta configurati correttamente tutti questi elementi, si dovrebbe essere in grado di utilizzare il debugger e il
code light.
In caso di problemi, tornate al mio video per la configurazione sulla vostra piattaforma.
Debugger e Code Light.
Il concetto più importante del debugger è quello di breakpoint.
Un punto di interruzione è qualcosa che si può impostare nel programma e che interrompe l'esecuzione
del codice.
Si può essenzialmente dire: "Ehi, voglio fermarmi a questa riga e il programma,
quando si esegue il debugger, si fermerà a quella riga".
Consente di analizzare il codice una riga alla volta per cercare di diagnosticare e risolvere eventuali
problemi.
Normalmente, quando si esegue il programma, se si cerca di eseguirlo nel debugger e non è stato impostato un punto di interruzione,
non succederà nulla.
Quindi, normalmente, quando si costruisce, si può andare a costruire il progetto come qualsiasi
altro progetto, andare a costruire, andare a costruire il progetto.
Quando lo si costruisce e lo si esegue in modalità di debug, si deve accedere all'opzione di menu del debugger
e andare su start, continua debugger.
Quando lo si esegue di nuovo, se è stato impostato un punto di interruzione, viene raggiunto.
Se non è stato impostato un punto di interruzione, il programma verrà eseguito.
Quindi, se proviamo a eseguire questo programma in modalità debug, viene fuori e chiede di dare invio
perché si ferma proprio ai numeri e quindi basta premere qualche numero e si chiude.
Non stampa nemmeno le informazioni, giusto?
È quindi molto importante, se si vuole utilizzare il debugger, avere almeno un punto di interruzione impostato.
Il modo più semplice per impostare un punto di interruzione è quello di fare semplicemente clic all'interno del margine dei numeri di riga sul numero
di riga che si desidera impostare.
E ancora, un punto di interruzione interromperà l'esecuzione su quel numero di riga.
Quindi, se impostiamo un punto di interruzione proprio accanto alla funzione printf alla riga dieci, facciamo un doppio clic e vedremo
che si posizionerà un cerchio rosso.
Questo dice al debugger: "Ehi, fermati alla riga dieci".
Quindi, ancora una volta, il modo in cui si avvia il debugger è quello di andare su debugger e dire: start, continue, giusto?
Tutto il resto è in grigio, giusto?
Avviamo quindi il debugger per raggiungere il punto di interruzione.
Avviamo quindi il debugger e diciamo build e debug e noteremo che il
programma si ferma alla riga dieci.
Si vede la freccia verde, e si vede anche che è comparso il riquadro del debugger.
Quindi, se si va in visualizzazione, è possibile visualizzare il pannello del debugger manualmente o automaticamente
quando si entra in modalità di debug e il pannello del debugger ha molte schede diverse per le informazioni che possono essere visualizzate.
Si può anche esaminare attraverso il debugger, andando su GDB windows, e si possono vedere tutti quelli che sono
controllati.
Ci sono molte finestre di debugger che si possono consultare.
Quindi i locali di solito hanno a che fare con gli orologi delle variabili locali.
È possibile inserire un orologio su una variabile, in modo che se la variabile cambia venga visualizzata.
Output è da utilizzare per le diverse opzioni di debug e per i thread di output.
È possibile osservare i thread che stanno eseguendo il programma.
Il concetto più avanzato di Callstack è quello su cui ci concentriamo.
In pratica guardiamo lo stack delle chiamate e i locali.
Questi sono i due più importanti che aiutano il debug e poi la memoria e i punti di interruzione.
È possibile vedere dove sono impostati i punti di interruzione.
Quindi molte opzioni diverse.
Al momento siamo fermi alla linea dieci.
Possiamo esaminare lo stack delle chiamate.
Lo stack delle chiamate ci mostra che è stata chiamata la funzione principale.
Se osserviamo i locali, ci mostra tre variabili: zero, uno e zero.
Non abbiamo inserito alcuna informazione in questi campi, che sono inizializzati a zero uno e zero.
L'orologio può essere aggiunto.
Aggiungere premendo il segno più per aggiungere un orologio a una particolare variabile.
E l'altra cosa importante da notare è che quando si esegue in modalità debug, ora si ha la barra degli
strumenti per il debugger, giusto?
Il pulsante di riproduzione continuerà a funzionare.
Così andrà.
Se premo play, il programma uscirà, giusto?
Inizierà a funzionare.
Il programma chiederà effettivamente un input.
Quindi ho premuto play.
Torno all'applicazione della console e mi dice Invio.
Così ho raggiunto i miei tre numeri nelle esecuzioni del programma.
Allora non avete ancora visto la funzione di stampa.
La finestra è sparita.
Quindi, ancora una volta, eseguiamo in modalità di debug e il programma passa di nuovo al punto di interruzione, il riquadro del debugger viene visualizzato e si
ferma alla riga dieci.
La barra degli strumenti è importante, perché è il modo in cui si può effettivamente procedere con il
codice e si può usare la barra degli strumenti o salire al debugger e dare un'occhiata a tutte le opzioni qui sopra.
Quindi si può dire che l'istruzione step into step into next, l'istruzione successiva, step out, step into andranno all'interno
di una funzione.
Se su quella riga viene richiamata una funzione, l'istruzione step into va più sul tipo di linguaggio
assembly.
Passiamo quindi a questa riga di codice.
E le istruzioni per il collo sono più o meno la stessa cosa.
Step out, cerca di uscire da una funzione se si è già in una funzione e di passare alla linea di carota.
In realtà penso che vada al cursore.
Lo stesso vale per la corsa alla linea della carota.
È possibile attivare e disattivare i punti di interruzione, disabilitarli tutti e così via, in modo da potervi accedere tramite
il menu.
O ancora, la barra degli strumenti.
Di solito uso la barra degli strumenti perché è già attiva.
E se si osservano di nuovo le diverse finestre, lo stack delle chiamate locali e i punti di interruzione.
Quelli davvero importanti.
Questo dice che ho un punto di interruzione alla riga dieci.
E poi penso che uno dica solo il cursore.
Quindi mi sono fermato qui a print F enter alla riga dieci.
Posso passare all'istruzione successiva e questo andrà alla scansione della riga 11.
F è in realtà una funzione bloccante che richiede un input.
Quindi, se provo ad andare avanti, si mette in pausa.
Potrebbe essere necessario premere più volte "next".
Di solito, quando il programma chiede un input e io lo voglio, è già bloccato, si è già fermato e voglio
che passi al prossimo.
Metterò un punto di interruzione sulla riga successiva e premerò il tasto play.
Quindi ora premo il pulsante di riproduzione e non succede nulla perché è in attesa di input.
Nel programma c'è scritto Invio.
Quindi posso premere cinque, sei, sette, premere il pulsante di invio e ora raggiunge il mio punto di interruzione.
Ora siamo al pulsante di stampa e possiamo accedere alla funzione di stampa.
E in realtà prima salta alla funzione media.
Se diciamo "step into", vediamo che passiamo alla funzione media.
E quello che noterete è che se guardate le vostre variabili, potete vedere come cambiano le vostre variabili.
Quindi, se si va avanti, si passa alla riga successiva del 27, poi al 28 e si continua a colpire.
Poi, si salta fuori e si arriva alla fine della funzione.
Quindi si può premere play e si può vedere che il programma è stato completato e la finestra è scomparsa.
Ma si possono esaminare le variabili e tutto il resto.
Quindi, ancora una volta, è possibile inserire un punto di interruzione all'interno della funzione di stampa proprio qui.
E se si esegue questa operazione, si può notare ancora una volta che la funzione di stampa interrompe l'esecuzione al posto della
media.
E poi possiamo vedere cosa succede nella versione attuale, se andiamo a vedere l'applicazione,
si può vedere che le informazioni sono state stampate.
Giusto?
Quando si continua, quando si arriva alla fine, si ottiene l'istruzione return e il programma esce.
Quindi è importante, se si vuole vedere l'output del programma, posizionare un punto
di interruzione prima del ritorno e non continuare.
È possibile arrestare il debugger premendo il rettangolo rosso, mettere in pausa il debugger premendo le
due barre parallele, riavviare il debugger con questa opzione e il callstack.
Anche in questo caso, è più facile da vedere se si entra in una funzione e si esegue il debugger.
Dire debugger, avviare, continuare.
Quando si raggiunge il punto di interruzione dopo aver inserito le informazioni all'interno di una funzione, si vedrà che lo stack
di auto ha il main e il print, proprio come abbiamo mostrato prima.
In questo modo si può vedere l'ultima funzione che è stata invocata. In un programma con molte funzioni e così via, lo stack
delle chiamate può diventare molto più grande di questo.
L'unica altra cosa che potrebbe essere importante sono i punti di interruzione.
Se volete vedere quali punti di interruzione avete impostato, vi mostrerà tutti i punti di interruzione e l'intero programma
in cui si trovano.
Ma dovrete giocarci, familiarizzarvi, prenderci confidenza e usarlo spesso per i problemi che
non riuscite a risolvere con le tecniche di debug o i programmi di base.
Crash procede riga per riga.
Procedendo riga per riga, è possibile vedere l'uscita del programma quando si blocca
e sapere su quale riga si è verificato.
Anche in questo caso, si tratta di un programma di piccole dimensioni, ma si dovrebbe ottenere una comprensione di base del funzionamento del debug.
Ancora una volta, spero che questo sia stato utile.
Il modo migliore per imparare queste cose è iniziare a giocarci e a usarle.
Tirate fuori uno dei programmi su cui avete lavorato nella sfida precedente.
Aggiungere un punto di interruzione, molto semplice.
È sufficiente fare clic all'interno dell'oggetto per aggiungere punti di interruzione.
Avviatelo in modalità di debug e scorrete ogni riga per vedere come cambiano le variabili e come aumenta lo
stack delle chiamate.
Se avete funzioni più grandi.
Grazie.