Newsgroup: it.comp.lang.c
Titolo: break point

ciao a tutti...
non riesco a far fermare il programma ai break point inseriti e soprattutto
dopo averlo compilato la prima volta non mi da il "go".
Il compilatore č il visual c.
grazie a tutti....
URGENTE

 ha scritto nel messaggio
news:oqzB8.17631$US3.4...@twister1.libero.it...

cosa usi per fermare il codice ... scanf(..) ?
non capisco cosa intendi .. con non mi da il go, potresti chiarire meglio

Premessa...sono ignorante...
per inserire i break point uso la manina, poi gli do "esegui programma",ma
non mi si ferma....


assicurate che la configurazione corrente sia Win32 Debug (Build->Set
Active Configuration) poi fai Build->Build, e dopo aver posizionato i
breakpoint, build->Start debug->go, e il programma si fermerà sul
primo breakpoint, se quella funzione per un qualunque caso non venisse
mai chiamata ovviamente il debugger non brekkerà mai, comunque puoi
anche fare Build->Start Debug->Step Into e steppare istruzione per
istruzione (brekkando sulla main (o WinMain))
ciao!
P.S.: sono nuovo del ng, ciao a tutti :)

 ha scritto nel messaggio
news:t5jdduoq2mjj62c83...@4ax.com...


non mi si ferma....
Non ho mai usato il Visual C, ma i break point di cui parli sono
funzioni del debugger.
Per abilitare queste funzioni devi aver compilato il programma in modo
da includere tutte le info per il debugger (in pratica gli includi il
codice sorgente e varie altre informazioni che gli dicono che pezzo
del sorgente sta eseguendo).
Devi controllare che il compilatore infili tutte le informazioni
necessarie a debuggare (potrebbe farlo in automatico, ma spero di no).
Potresti:
a) dover attivare qualche flag particolare che gli dica di inserire
info per il debug
b) prima inserire i break point e poi ricompilare, sperando che se ne
accorga e ricompili inserendo le info necessarie.
Se tu debuggi un programma che NON contiene le info necessarie
semplicemente il debugger non potra' mai arrestare la run.
Se tutto funziona correttamente all'azione "RUN" deve corrispondere un
avanzamento fino al break point da te indicato, mentre uno "STEP"
dovrebbe andare all'istruzione successiva (non necessariamente la riga
successiva, attenzione).
-- 
Mox
"Trust the programmer."
"Don't prevent the programmer from doing what needs to be done."
"Keep the language small and simple."
"Provide only one way to do an operation."

 successiva, attenzione).
Esistono 2 tipi di step e sono 
Step Into e Step Over 
Step Into permette di segure il flusso del codice anche dentro le
eventuali
chiamate a funzione che si dovessero incontrare (cmq sarebbe meglio
avere una certa familiarità con l'asm quando si fa del debugging per
capire bene)
Step Over salta oltre le chiamate a funzione, le quali vengono
ovviamente eseguite ma come un blocco unico e non istruzione per
istruzione come nel caso della modalità precedente
Ciao 
NikDH

0xCC che si trovano nel codice del programma
Uhmm, quindi se non compilo con le opzioni di debug potrei comunque
debuggare inserendo dei break point, non a livello di codice sorgente
C, ma a livello di disassemblato.
Il che comunque bloccherebbe la maggior parte dei debugger integrati
come quello del VC++ perche' lavorano sul sorgente, giusto?


NikDH stai qua e manco mi saluti? :(((
ciao :)

be non è del tutto esatto, con il visual c puoi comunque debuggare ma
vedi il codice asm e non il sorgente

 ciao :)
Ciao Quake2, 
devi scusarmi ma non pensavo fossi proprio tu (anche se avevo un vago sospetto) 
:))) 
Anyway sono felice di vedere anche te qui :) 
Ciao 
NikDH