Magnifica la sessione di Steve Teixeira sul debugging di codice nativo con Visual C++ 2008. Alcune di queste cose sono anche presenti nella versione 2005 ma in tanti nella sala non ne conoscono l'esistenza, quindi Steve passa all'attacco e spara a raffica una serie di fantastici tips&tricks.
- Lo switch /GS per trovare i problemi di Buffer Overrun
- Secure Iterators nelle STL abilitato di default e controllato con _SECURE_SCL
- Static Code Analisys compie una analisi del codice prima del deploy e identifica eventuali errori in compilazione. Di default è disabilitato e usando SourceAnnotation.h si può usare il linguaggio SAL per inserire dei metadati che danno la possibilità al compilatore cosa stiamo cercando di fare con quelle variabili e di avvisarci di conseguenza. Per esempio il fatto che un puntatore sia un parametro di solo output oppure che non possa essere mai NULL. Con queste annotazioni si ottengono dei warning che rivelano errori potenzialmente fatali, non solo in materia di sicurezza.
- Raccomandazione di usare ENSURE, le varie assert e più in geneale codice che sia ricco di informazione che facilitono il debugging.
- Grazie ai property sheet si possono creare un insieme di settings specifici per i progetti in cui decidere il tipo di build da creare. Per esempio in retail è sempre bene produrre i pdb da conservare per ogni build consegnata al cliente. Diversamente non si ha la possibilità di fare crash dump analisys.
- Nuove facilities per l'uso di breakpoint come il count, i filtri, condizioni, data breakpoint e i fantastici trace point che permettono di mandare un messaggio nella output window e modificare anche i registri con la sintassi !{eip=0x12345678} dove "!" sta per execute.
- Edit & Continue e la bella notizia è che sarà molto migliorato in Visual Studio 10 (post-2008)
- Immediate window per valutare le variabili o invocare funzioni e Command Window per controllare l'IDE da tastiera (basta digitare immed o cmd nella finestra immediate per cambiare modalità)
- Autoexp.dat per formttare come meglio si crede l'output nelle finestre del debugger oppure per evitare di eseguire una funzione durante lo step-by-step
La demo finale e sul crash dump dove Steve sottolinea la necessità di creare sempre i simboli per ogni build che viene consegnata
È molto importante iscriversi a "winqual" per chi vende software perché Microsoft fornisce al produttore i crash dump dell'applicazione che va in crash. In pratica se il cliente della nostra applicazione ha un crash e spedisce il dump, Microsoft ce lo consegna e noi possiamo identificare il problema!