&Notanbsp; Esta nota técnica fue escrita para Windows 3.1. Windows NT implementa la mayoría de estas características. Cuando se ejecuta la aplicación con Windows 3.1 (con la DLL de Win32s), pueden ayudar a estas técnicas de depuración. Windows 95 también implementa y amplía las características de robustez, puestas en marcha durante Windows 3.1. Ejecutando la versión de depuración de Windows 95 es la mejor manera de asegurar su aplicación se está ejecutando limpiamente.
Windows 3.1 es una mejora importante sobre Windows 3.0 en el área de desarrollo de aplicaciones robustas. Windows 3.1 incluye una serie de nuevas características que mejoran la fiabilidad de una aplicación de Windows. Esta nota técnica describe el uso de estas funciones dentro de la biblioteca MFC.
Estas características incluyen el núcleo de depuración, estricta comprobación de tipos, diagnósticos y administración de la memoria y la WINDOWSX.Mejoras de h.
Núcleo de depuración de Windows 3.1
&Notanbsp; Esta sección sólo se aplica a Microsoft Visual C++ versión 1.5.
Prueba una aplicación MFC con los ejecutables del sistema de depuración es probablemente lo mejor que puede hacer para asegurarse de que sus aplicaciones son sólidas y fiables. Las versiones de depuración de los ejecutables del sistema realizan a todo tipo de útiles comprobación de errores para usted, informándole de los problemas que surgen con los mensajes de salida de depuración.
Es la mejor manera de utilizar el sistema de depuración con dos máquinas: una máquina de pruebas y depuración que tiene instalado el sistema de depuración y una máquina para el desarrollo. Una máquina, el equipo de prueba, siempre se debe ejecutar con el kernel de depuración. La máquina, el equipo de desarrollo, se debe ejecutar con el kernel no depuración. La salida desde el núcleo de depuración puede enviarse a la máquina principal en una línea de módem nulo. Si tiene sólo una única máquina, debe asegurarse ejecutar el kernel de depuración (hay una degradación del rendimiento leve). La salida desde el núcleo de depuración puede enviarse a DBWIN, una herramienta que se incluye con Microsoft Visual C++ versión 1.5. Además, la ventana resultados de Visual C++ recibirán salida cuando se ejecuta bajo el depurador.
Un truco útil para la depuración de la máquina solo es colocar copias de los archivos binarios de sistema y depuración y símbolos en un directorio separado y tener archivos por lotes que copie los archivos correspondientes a su directorio de sistema de Windows. De esta manera puede salir de Windows y alternar rápidamente entre depuración y no debug. El programa de instalación de Visual C++ versión 1.5 establecerá esto y, a continuación, puede cambiar entre la versión de Windows con el D2N no depuración y depuración.BAT y N2D.Archivos de proceso por lotes BAT.
Si no se ejecuta con un depurador o un terminal de depuración, debe ejecutar la aplicación DBWIN para que pueda ver los mensajes de error y advertencia producidos por el sistema de depuración. Esta aplicación se incluye con la versión 1.5 de Visual C++.
A continuación están algunos errores de programación comunes que aparecen con frecuencia en aplicaciones de Windows enviadas. Muchos de estos problemas pueden causar otros problemas bajo Windows 3.0 y sistema aleatorio UAEs. Los binarios de sistema de depuración le ayudará a localizar problemas, tales como:
Diagnósticos MFC
Además, Microsoft Foundation Classes se suministran con un conjunto de características de robustez que se compilan y vinculados sólo en la versión de depuración de la biblioteca (esas variantes de biblioteca que termina con un había '). Uso de estas características en las solicitudes de escritura en las clases de que diseño mejorará considerablemente el tiempo de ejecución y la captura de errores de tiempo de compilación de la aplicación. Estas funciones se describen a continuación, pero todos están documentadas en el manual de Referencia de la biblioteca de clase.
Cada clase derivada de CObject en MFC implementa una función miembro Dump , que permite ver el estado de un objeto en un formato ASCII. Esta función puede llamar desde el depurador o colocar porciones de /#endif # ifdef _DEBUG del código. Una función auxiliar AfxDump está incluida en la biblioteca de depuración sólo para este propósito. Se le llama con un solo parámetro, un CObject *. Esta función se puede llamar desde el depurador para imprimir el argumento. Debe proporcionar a un miembro Dump para las clases que implementan. Como con AssertValid, primero debe llamar explícitamente su volcado función de miembro de clase base. La salida de volcado se enruta a la estándar MFC CDumpContext, afxDump, que, por defecto, va a la ventana de resultados del depurador o a su depuración terminal. También puede utilizar el programa DBWIN para ver la salida de afxDump. El archivo de origen MFC\SRC\DUMPINIT.CPP incluye información sobre cómo enrutar afxDump a otro destino.
TRACE, una macro que se comporta más como printf, sólo rutas de salida para la ubicación de afxDump . Debe utilizar instrucciones de seguimiento para indicar lugares difíciles o excepcionales en el código. Como con otras características de robustez, TRACE sólo tiene sentido en la biblioteca de depuración y no tiene ningún efecto en la versión de venta por menor. La biblioteca MFC incluye un número de construido en instrucciones de seguimiento para el flujo de mensajes de seguimiento. Consulte 7 de nota técnica para obtener más información sobre seguimiento de depuración.
ASSERT es una comprobación en tiempo de ejecución para la validez de una declaración. Debe utilizar ASSERTs liberalmente a lo largo de su programa. Cualquier lugar tienes un comentario en el sentido de:
/ / lpStr debe ser NULL en este momento
debe reemplazar con una aserción de tiempo de ejecución:
Assert(lpStr == NULL)
El compilador no puede entender el comentario, pero puede evaluar la expresión en la macro de afirmación. Instrucciones ASSERT no tienen efecto en compilaciones de minoristas. Si necesita la información de ASERCIÓN en la versión de venta por menor, a continuación, utilizar la macro verificar.
MFC también incluye un asignador de memoria amplia de diagnóstico. Utilizar el asignador de memoria diagnóstico para comprobar que liberar todos los recursos de memoria durante ciertas funciones del programa. El asignador de diagnóstico registrará el archivo de origen y la línea número de una asignación, por lo que si se utiliza la CMemoryState::DumpAllObjectsSince API, puede localizar cualquier asignación que permanecen.
De forma predeterminada, MFC le devolverá todos los objetos no liberados por el programa (si hay alguno) antes de que el programa termina. Puede ver esta salida al ejecutar la aplicación bajo el depurador.
Comprobación de tipos estricta de Windows 3.1
Comprobación de tipos estricta es una opción disponible con WINDOWS.Archivo de encabezado de H. MFC utiliza estos tipos estricta de forma predeterminada, y se debe utilizar si está creando una aplicación MFC. MFC ya no admite la creación de una aplicación sin las definiciones de estricta.
Typesafe vinculación estricta y
En C++ puede tener muchas funciones con el mismo nombre, como estas funciones tienen listas de parámetros formales diferentes. A fin de tener símbolos de enlace único, el compilador de C++ se "decorar" estos nombres usando un algoritmo que codifica la información acerca de una función, como el nombre, número y tipo de parámetros formales, llamada Convención, etc.
Este nombre recién generado se usa como símbolo de enlace externo para la función. Esto se conoce como vinculación typesafe y es un gran beneficio de C++. Esta decoración de nombres no se aplica a funciones dentro de un bloque de extern "C", y que por eso todas las API de WINDOWS.H se encuentran en un bloque de tal.
Tipo de estricto control en WINDOWS.H mejora la seguridad de tipos para programas de Windows mediante el uso de distintos tipos para representar todos los IDENTIFICADORES diferentes en Windows. Así, por ejemplo, estricta le impide pasar erróneamente un HPEN a una rutina esperando un HBITMAP.
Desde las API de Windows están todos dentro de los bloques de {} extern "C", ellos no están decoradas en la forma descrita anteriormente. Estricta cambia los tipos de los diversos typedefs de Windows para hacerlos únicos (específicamente utiliza puntero diferentes tipos para representar s manejar, que no se puede convertir libremente sin una conversión explícita).
Como puede ver, si tienes estricta tipo comprobación activada en un archivo, pero no en otro, el compilador de C++ generará símbolos diferentes enlace externo para una sola función. Esto dará como resultado errores en tiempo de vínculo. Por lo tanto, se recomienda utilizar tipo de estricta comprobación sólo para módulos C (aquellos que terminen en.C). Además, estricta es sólo opción un tiempo de compilación, por lo que una vez correctamente compilar el código, completamente se obtienen los beneficios de la estricta.
Si se mezcla estricta y no-estricto código, debe ser consciente de las incoherencias de vinculación. En general, toda la programación de MFC y C++ todos deben realizarse con estricta. Si tienes código c legado, entonces no uso estricto es aceptable.
Windows 3.1 WINDOWSX.H archivo de encabezado
El WINDOWSX es nuevo con Windows 3.1 y Win32.Archivo de encabezado de h que soporta varias extensiones al estilo c de codificación para los programadores de Windows usando C. Estos macro APIs, galletas de mensaje y control API se definen en el archivo WINDOWSX.H.
Esta sintaxis está diseñada principalmente para programadores de C. MFC admite el uso de WINDOWSX.H, por lo que si tienes código existente que depende de estas tensiones, utilice este código no modificado en MFC. Sin embargo, encontrará que MFC tiene modismos comparables para todas las funciones de WINDOWSX.H y lenguaje C++ utiliza para realizar estas tareas con más seguridad semántica y arquitectura.
Para utilizar WINDOWSX.H, asegúrese de # incluirlo antes de que han incluido AFXWIN.H (o STDAFX.H si está utilizando la estructura de AppWizard).
La única salvedad es que hay dos WINDOWSX.H APIs que chocan con las APIs de C++ de MFC. Las API de dos SubclassWindow y CopyRgn no están disponibles para su uso en MFC. Será necesario recodificar a utilizar la API de MFC (y clases) o llamar a la API de Windows directamente. También puede codificar sus propias macros como tiene un nombre diferente.
&Notas técnicas por número |nbsp; Notas técnicas por categoría