&Notanbsp; Questa nota tecnica è stato scritto per Windows 3.1. Windows NT implementa la maggior parte di queste caratteristiche. Quando si esegue l'applicazione sotto Windows 3.1 (con le dll Win32s), queste tecniche possono aiutare nelle operazioni di debug. Windows 95 anche implementa ed estende le caratteristiche di robustezza, messe in atto nel corso di Windows 3.1. In esecuzione la versione di debug di Windows 95 è il miglior modo per assicurare l'applicazione è in esecuzione in modo pulito.
Windows 3.1 è un grande miglioramento sopra Windows 3.0 nell'area dello sviluppo di applicazioni robuste. Windows 3.1 comprende una serie di nuove caratteristiche che migliorano l'affidabilità di un'applicazione Windows. Questa nota tecnica viene descritto l'utilizzo di queste funzionalità all'interno della libreria MFC.
Queste funzionalità includono il kernel di debug, controllo del tipo STRICT , diagnostica e gestione della memoria e la WINDOWSX.Miglioramenti H.
Kernel di Windows 3.1 Debug
&Notanbsp; In questa sezione si applica solo a Microsoft Visual C++ versione 1.5.
Test dell'applicazione MFC con gli eseguibili di sistema di debug è probabilmente la cosa migliore che puoi fare per assicurarsi che le applicazioni sono robusti ed affidabili. Le versioni di debug degli eseguibili sistema eseguono tutti i tipi di controllo utili degli errori per voi, per informare l'utente di eventuali problemi che sorgono con i messaggi di output di debug.
Il modo migliore per utilizzare il sistema di debug è con due macchine: una macchina per test e debug che ha installato il sistema di debug e una macchina per lo sviluppo. Una sola macchina, la macchina di test, deve essere sempre eseguita con il kernel di debug. La macchina, computer di sviluppo deve essere eseguita con il kernel non di debug. L'output di debug del kernel può essere inviato alla macchina primaria su una linea di null-modem. Se avete solo una singola macchina, dovrebbe essere sicuri di eseguire il debug kernel (c'è un degrado delle prestazioni leggero). L'output di debug del kernel può essere indirizzato a DBWIN, uno strumento incluso in Microsoft Visual C++ versione 1.5. Inoltre, la finestra di Output di Visual C++ riceverà uscita quando si esegue nel debugger.
Un trucco utile per il debug solo computer è di inserire copie di file binari di sistema e di debug e simboli in una directory separata e di avere i file batch che copiare i file appropriati alla directory di sistema di Windows. In questo modo puoi uscire Windows e passare avanti e indietro velocemente tra debug e non di debug. Il programma di installazione di Visual C++ versione 1.5 questo sarà istituito, quindi è possibile passare tra debug e non di debug versione di Windows con il D2N.PIPISTRELLO e blogzeri.BAT file batch.
Se voi non sono in esecuzione con un debugger o un terminale di debug, è consigliabile eseguire l'applicazione DBWIN così si può vedere l'errore e i messaggi di avviso prodotti dal sistema di debug. Questa applicazione è inclusa in Visual C++ versione 1.5.
Di seguito sono alcuni errori di programmazione comuni che compaiono frequentemente in applicazioni Windows spedite. Molti di questi problemi possono causare UAEs sistema casuale e altri problemi sotto Windows 3.0. I file binari di sistema di debug vi aiuterà a tenere traccia dei problemi, come ad esempio:
MFC diagnostica
Inoltre, la Microsoft Foundation Classes nave con un insieme di caratteristiche di robustezza che vengono compilati e linkati solo nella build di debug della libreria (quelle varianti di libreria che termina con un aveva '). Utilizzo di queste funzionalità in applicazioni si scrive e nelle classi che si progetta notevolmente migliorare sia il runtime e intercettazione di compilazione dell'applicazione tempo. Queste funzioni sono descritte di seguito, ma tutti sono documentati nel manuale di Riferimento alla libreria di classi.
Ogni classe derivata da CObject in MFC implementa una funzione membro Dump , che consente di visualizzare lo stato di un oggetto in un formato ASCII. Questa funzione può essere chiamata dal debugger o collocata all'interno di porzioni di /#endif # ifdef debug del codice. Una funzione di supporto AfxDump è incluso nella libreria di debug solo per questo scopo. Esso viene chiamato con un solo parametro, CObject *. Si può chiamare questa funzione dal debugger per stampare fuori l'argomento. È necessario fornire un membro Dump per le classi che implementano. Come con AssertValid, si dovrebbe innanzitutto chiamare in modo esplicito classe base funzione membro Dump . L'output del Dump viene indirizzato agli standard MFC CDumpContext, afxDump, che, per impostazione predefinita, va nella finestra di output del debugger o per il vostro terminale di debug. È anche possibile utilizzare il programma DBWIN per visualizzare l'output di afxDump. Il file di origine MFC\SRC\DUMPINIT.CPP include informazioni su come indirizzare afxDump a un'altra destinazione.
Traccia, una macro che si comporta molto come printf, solo percorsi di uscita nel percorso afxDump . Per indicare i luoghi eccezionali o ingannevole nel codice, è necessario utilizzare istruzioni di analisi . Come con altre caratteristiche di robustezza, traccia è significativa solo nella libreria di debug e della compilazione di vendita al dettaglio non ha alcun effetto. La libreria MFC comprende un certo numero di costruito in istruzioni di analisi per il monitoraggio del flusso dei messaggi. Per ulteriori informazioni sulla traccia di debug vedere 7 Note tecniche.
ASSERT è un controllo Runtime per la validità di un'istruzione. È consigliabile utilizzare ASSERTs liberamente in tutto il programma. Qualsiasi luogo si avere un commento all'effetto:
/ / lpStr dovrebbe essere NULL, a questo punto
è che dovrebbe sostituire con un'asserzione di runtime:
Assert(lpStr == null)
Il compilatore non può capire il commento, ma può valutare l'espressione nella macro asserzione. Istruzioni ASSERT hanno alcun effetto nelle compilazioni di vendite al dettaglio. Se è necessario che le informazioni da ASSERT nella build al dettaglio, quindi utilizzare la macro VERIFY.
MFC include anche un allocatore di memoria diagnostico estesa. Utilizzare l'allocatore di memoria diagnostico per verificare che si libero tutte le risorse di memoria durante alcune funzioni del programma. L'allocatore di diagnostica terrà traccia il file di origine e la linea numero di un'allocazione, quindi se si utilizza il CMemoryState::DumpAllObjectsSince API, è possibile individuare eventuali allocazioni che rimangono.
Per impostazione predefinita, il MFC dump tutti gli oggetti non liberati dal vostro programma (se ve ne sono) prima che il programma viene chiuso. È possibile visualizzare questo output eseguendo l'applicazione nel debugger.
Windows 3.1 tipi rigorosa verifica
Controllo del tipo STRICT è un'opzione disponibile con le finestre.File di intestazione H. MFC utilizza questi tipi STRICT per impostazione predefinita ed è necessario utilizzare se si costruisce un'applicazione MFC. MFC non più supporta la creazione di un'applicazione senza le definizioni STRICT.
Linkage indipendente dai tipi e rigorosa
In C++ sono consentiti per avere molte funzioni con lo stesso nome, purché queste funzioni sono elenchi di parametri formali diversi. Per avere i simboli link univoco, il compilatore C++ "decorerà" questi nomi utilizzando un algoritmo che codifica le informazioni su una funzione come il nome, numero e tipo di parametri formali, chiamata la convenzione, ecc.
Questo nome appena generato viene utilizzato come simbolo link esterno per la funzione. Questo è conosciuto come indipendenti dai tipi collegamento ed è un grande vantaggio di C++. Questa decorazione di nome non si applica alle funzioni all'interno di un blocco di extern "C", ed ecco perché tutte le API di WINDOWS.H sono in un blocco di tali.
Controllo in WINDOWS di tipo STRICT .H aumenta la sicurezza di tipo per i programmi Windows utilizzando tipi distinti per rappresentare tutte le maniglie differenti in Windows. Così, per esempio, STRICT ti impedisce di erroneamente passando un HPEN a una routine prevedendo un HBITMAP.
Poiché le API di Windows sono tutti all'interno di blocchi di {} extern "C", non sono decorate nel modo descritto sopra. STRICT cambia i tipi dei vari Windows typedef per renderli unici (in particolare utilizza tipi puntatore diversi per rappresentare gestires, che non possono essere convertite liberamente senza un cast esplicito).
Come potete vedere, se avete STRICT controllo del tipo abilitato in un unico file, ma non in un altro, il compilatore C++ genererà simboli diversi link esterno per una singola funzione. Questo si tradurrà in errori in fase di collegamento. Pertanto, è consigliabile utilizzare tipo STRICT verifica solo per moduli C (quelli che terminano in.C). Inoltre, STRICT è opzione solo una fase di compilazione, così quando viene compilato correttamente il codice, i benefici di STRICT sono completamente realizzati.
Se sono di miscelazione STRICT e non-STRICT codice, è necessario essere consapevoli di incoerenze di collegamento. In generale, tutta la programmazione MFC e C++ tutto dovrebbe essere fatto con STRICT. Se avete il codice c legacy, quindi non utilizzando STRICT è accettabile.
Windows 3.1 WINDOWSX.H il File di intestazione
Nuovo con Windows 3.1 e Win32 è il WINDOWSX.File di intestazione h che supporta varie estensioni allo stile c a livello di codice per i programmatori di Windows utilizzando c. Queste macro API, cracker di messaggio e controllo API sono definiti nel file WINDOWSX.H.
Questa sintassi è stata progettata principalmente per programmatori C. MFC supporta l'utilizzo di WINDOWSX.H, quindi se avete il codice esistente che si basa su queste tensioni, utilizzare questo codice non modificato in MFC. Tuttavia, troverete che MFC ha idiomi comparabili per tutte le caratteristiche di WINDOWSX.H e linguaggio utilizza il C++ per eseguire queste attività con maggiore sicurezza semantica e architettonica.
Per utilizzare WINDOWSX.H, assicurarsi di # includerlo prima di voi hanno incluso AFXWIN.H (o STDAFX.H se si utilizza la creazione guidata applicazione struttura).
L'unica avvertenza è che ci sono due WINDOWSX.H API che si scontrano con le API C++ MFC. Le due API SubclassWindow e CopyRgn non sono disponibili per l'uso all'interno di MFC. Bisogno per ricodificare questi per utilizzare le API di MFC classi (e) o chiamare direttamente l'API di Windows. Si può anche codice proprie macro, purché esso ha un nome diverso.
&Note tecniche per numero |nbsp; Note tecniche per la categoria