sintesi della presentazione dell`ambiente di

Tutorial su Codelite
Luca Ceriani
<[email protected]>
© 2011 Federico Cerutti <[email protected]>
Sommario
• Creare un nuovo workspace
• Creare un primo progetto all’interno di un workspace
– Scrittura del programma
– Esecuzione
– Esecuzione controllata tramite il debugger
• Scrivere un secondo programma all’interno dello stesso
workspace
• Strumenti di Codelite per evidenziare errori di
programmazione
CREARE UN NUOVO WORKSPACE
Scrivere il nome del Workspace
Selezionare la directory per il workspace
CREARE UN PRIMO PROGETTO
ALL’INTERNO DI UN WORKSPACE
Useremo solamente la categoria “Console”…
…e la tipologia “Simple executable (gcc)”
Scriviamo il nome del nuovo progetto
e clicchiamo su OK
All’interno dell’area di sinistra di Codelite, chiamata
Workspace View, compare, un albero la cui radice
è il nome del workspace che abbiamo creato, e sotto
di esso compare il primo progetto che abbiamo creato
Cliccando sul simbolo a sinistra di “NumeriBinari” si apre l’albero dei
file associati a questo progetto, quindi vedremo la directory “src” e se
apriamo anche questa directory compare il file “main.c”, che è il file che
conterrà il nostro codice.
Con il doppio
click su “main.c”
compare
nell’area centrale
di Codelite un
editor di testo
con il contenuto
di “main.c”
Selezioniamo il codice che viene autogenerato da Codelite e
cancelliamolo
A questo punto scriviamo il nostro codice (ricordarsi di salvare il codice
con CTRL+s o tramite il menù, selezionando File e poi Save File)
Compilazione ed esecuzione
Una volta terminato di scrivere il codice, possiamo compilarlo tramite
l’opzione “Build Project” evidenziata in figura
Nell’area in basso, nel tab “Build” compaiono le informazioni sulla
compilazione. Attenzione: non si potrà eseguire alcun programma fino a
quando in questo tab non comparirà la scritta “0 errors” come
evidenziato.
Se la compilazione è andata a buon fine, possiamo eseguire il programma
con il comando “Run” come evidenziato in figura
Comparirà una finestra del terminale del sistema operativo che stiamo
eseguendo (in questo esempio Windows XP) in cui viene eseguito il
nostro programma
Compilazione ed esecuzione controllata tramite il debugger
Impostiamo un breakpoint, ovvero un punto in cui il programma verrà
sospeso nel momento in cui lo eseguiamo tramite il debugger.
Per fare questo, clicchiamo accanto (alla destra) al numero della riga in
corrispondenza della quale vogliamo che l’esecuzione del programma si
sospenda (nell’esempio la riga 13).
Lanciamo l’esecuzione controllata tramite il comando “Start/Continue
Debugger”
Codelite ci chiede se vogliamo ricompilare il progetto prima di eseguirlo
mediante il debugger. Rispondiamo SEMPRE di sì
3
Compariranno/saranno visibili:
1. L’area delle informazioni di compilazione
(basso a sinistra)
2. L’area di informazioni del debugger (basso a
destra)
3. La finestra del terminale all’interno della
quale vedremo gli output del nostro
programma e potremo inserire gli input
1
2
Ad esempio, dopo aver inserito il numero
richiesto (in questo caso inseriamo 32),
l’esecuzione del programma si sospenderà al
breackpoint che abbiamo ipostato, e nel tab
“Locals” dell’area di informazione del debugger
vedremo le variabili locali e i relativi
assegnamenti.
La freccia verde indica la riga del programma
che il debugger sta per eseguire. In questo caso
è sovrapposta al bottone rosso che rappresenta
il breackpoint perché l’esecuzione è in questo
momento sospesa
Se selezioniamo il tab “Memory” nell’area di informazioni del debugger, possiamo
richiedere di visualizzare specifiche aree di memoria, richiedendo l’accesso con il
simbolo “&” seguito dal nome della variabile. Il debugger ci mostrerà i primi 32 byte a
partire dalla posizione che gli abbiamo richiesto (opzione modificabile cambiando il
parametro “Size”). Dobbiamo sapere noi quanti sono i byte che ci interessano
effettivamente. In questo caso abbiamo richiesto l’area di memoria della variabile
“un_numero_intero” che è un int, e quindi utilizza 32 bit (4 byte).
N.B. Il calcolatore da cui sono state tratte queste immagini lavora in Little-Endian.
N.B. la notazione “0xNM” equivale a (NM)h
Area di memoria della variabile
un_numero_intero, ovvero scriviamo
“&un_numero_intero”
Il valore della variabile “un_numero_intero”
esattamante come viene rappresentata nel
calcolatore (in questo caso un int quindi 4 byte,
su un’architettura Little-Endian)
Il numero di byte che chiediamo di visualizzare al
debugger (di default 32). Se in questa posizione
avessimo specificato “4”, avremmo visto solamente
i primi 4 byte, e quindi solo ed unicamente l’area di
memoria che ci interessava
In questo caso, richiediamo i primi 32 byte dell’area di memoria a partire da dove è stata
salvata la variabile un_altro_numero_intero
L’area di controllo del debugger è in alto a sinistra. In particolare, se premiamo sul
pulsante disegnato come un quadrato (evidenziato in figura) possiamo terminare
l’esecuzione del nostro programma in esecuzione controllata all’interno del debugger
SCRIVERE UN SECONDO PROGRAMMA
ALL’INTERNO DELLO STESSO
WORKSPACE
Ricordarsi sempre!!!!
Un programma, un progetto
Se vogliamo scrivere un nuovo programma,
cominciamo sempre creando un nuovo progetto.
Quindi, NON inserire nuovi file che rappresentano
altri programmi all’interno di un progetto già
esistente!!!
Se, come in questo caso, è rimasto aperto il file “main.c” del progetto precedente
(NumeriBinari), chiudiamolo cliccando sulla X che compare a destra del nome del file nel
tab relativo (come evidenziato in figura)
Apriamo l’albero del nuovo
progetto…
…doppio click sul file “main.c” del
nuovo progetto…
…al solito comparirà il codice
preimpostato da Codelite…
…cancelliamo il codice
preimpostato da Codelite…
…scriviamo il nostro codice.
Prima di compilare il nostro nuovo codice, dobbiamo cambiare il
progetto “active”, ovvero il progetto sul quale Codelite eseguirà le
operazioni di “Build Project” e di “Run” che gli andremo a
richiedere. Quindi clicchiamo sull’icona evidenziata in figura…
…comparirà la lista dei progetti presenti in questo workspace.
Selezioniamo il progetto che vogliamo compilare/eseguire…
…nell’albero del workspace, il progetto che abbiamo selezionato
come “Active” cambierà il suo font in grassetto. Quindi, se stiamo
scrivendo codice e non ci ricordiamo quale sia il progetto attivo,
basta guardare a sinistra: il progetto con il nome in grassetto è
quello impostato come “Active”.
A questo punto possiamo operare come visto in precedenza, quindi
possiamo compilare il progetto…
…eseguire il nuovo progetto…
…al solito comparirà il terminale del sistema
operativo che stiamo utilizzando, e potremo usare
questa finestra per fornire gli input e visualizzare
gli output…
…possiamo impostare breackpoint per l’esecuzione
controllata mediante debugger cliccando a destra
del numero di riga in corrispondenza della quale
vogliamo sospendere l’esecuzione del nostro
programma…
…lanciare l’esecuzione del nostro programma
nell’ambiente controllato del debugger…
…accettare che Codelite prima di eseguire il
programma attraverso il debugger lo ricompili…
…operare come
meglio crediamo
nell’ambiente del
debugger…
…operare come
meglio crediamo
nell’ambiente del
debugger…
…e alla fine terminare l’esecuzione del
nostro programma nell’ambiente
controllato del debugger.
STRUMENTI DI CODELITE PER
EVIDENZIARE ERRORI DI
PROGRAMMAZIONE
Creiamo un nuovo programma…
…scriviamo
Come possiamo
il nostro codice:
vedere,come
questo
possiamo
programma
vedere,contiene
ci sono 4 errori nel
codice:
1. Manca il “;” che termina la riga 3
2. Richiamiamo la printf su una variabile
che non esiste
3. Richiamiamo la funzione printf senza
aver importato la libreria <stdio.h>
4. Scriviamo “return = 2” invece che
“return 2;”
Impostiamo il nostro nuovo codice come
Active per poi vedere quale sia il risultato
della compilazione.
Nell’area delle informazioni di compilazione
vengono evidenziati gli (eventuali) errori di
compilazione. Inoltre Codelite presenta delle
frecce rosse in corrispondenza delle righe che
contengono gli errori rivelati dal compilatore.
N.B. Il compilatore potrebbe anche non
evidenziare tutti gli errori commessi
Se, nonostante gli errori di compilazione e
quindi prima di correggerli proviamo ad eseguire
il programma ad esempio attraverso il
debugger…
…e diciamo a codelite di non ricompilare il
progetto (contrariamente a quanto facciamo di
solito, quindi commettiamo anche questo
errore)…
…comparirà questa finestra di errore, che
significa che il debugger ha provato ad eseguire
un file eseguibile che non esiste ancora. Infatti,
fino a quando la compilazione non andrà a buon
fine, non verrà creato il nostro programma
eseguibile
PRIMA DI ESEGUIRE UN PROGRAMMA, SIA ATTRAVERSO IL COMANDO DI RUN, SIA
ATTRAVERSO L’ESECUZIONE CONTROLLATA MEDIANTE IL DEBUGGER, DOBBIAMO
RISOLVERE TUTTI GLI ERRORI DI COMPILAZIONE!!!!
Processo di correzione degli errori
Compilazione
Correzione
del primo
errore
Presenza di
errori
Iniziamo a correggere gli errori sempre dal
primo evidenziato, ricompiliamo e vediamo che
effetti ci sono.
La prima linea di errore ci informa che manca un
“;” prima del printf, quindi provvediamo ad
inserire questo “;”.
Ricompiliamo, e il compilatore ci informa che si
è accorto di 4 errori, il primo dei quali riguarda il
fatto che “numer” (parametro della funzione
printf) non è mai stato dichiarato come variabile.
Correggiamo quindi l’errore scrivendo il nome
corretto della variabile (ovvero “numero”)
Ricompiliamo e il compilatore presenta un errore ed
un warning. I warning sono errori che di cui il
compilatore ci avvisa e che ci informa che potrebbe
riuscire a correggere autonomamente, ma senza
alcuna garanzia. Quindi non devono essere ignorati. In
questo caso, il compilatore ci informa che non
abbiamo mai dichiarato la funzione “printf” perché in
precedenza non avevamo incluso la libreria <stdio.h>.
Quindi correggiamo questo warning scrivendo
“#include <stdio.h>” in principio al file sorgente
Ricompiliamo e il compilatore presenta un ultimo
errore, dovuto al fatto che la riga 9 è sintatticamente
sbagliata
Correggiamo l’errore…
…ricompiliamo, e a questo punto nell’area di
informazioni del compilatore compare la
scritta:
“0 errors, 0 warnings”, che significa che il
codice che abbiamo scritto è sintatticamente
corretto (nessuna garanzia sulla semantica) e
quindi possiamo eseguirlo attraverso il
comando “Run” o mediante l’esecuzione
controllata del debugger