03 programación c++ al completo

95
Programación C++ Adolfo J. Millán 1.4.4b2c Librería de importación §1 Sinopsis Las librerías de importación son librerías estáticas de terminación clásica .lib o .a, que no contienen código objeto, solo tablas. Cada entrada contiene el nombre de una DLL y la dirección de un recurso exportable dentro de la DLL. Por ejemplo, una función dllexport de la librería. Generalmente estas direcciones están en forma de números. Nota: los compiladores C/C++ pensados para escribir aplicaciones que correrán en la plataforma Win32 incorporan algunas de estas librerías con las direcciones de los recursos de la API de Windows (que está constituida por un conjunto de DLLs). Entre las más frecuentes de estas librerías de importación están: IMPORT32.LIB, KERNEL32.LIB, USER32.LIB, y GDI32.LIB. Estas librerías se enlazan estáticamente con la aplicación que debe utilizar los recursos de la DLL, de forma que el cargador del ejecutable (que debe cargar también las librerías) puede resolver las invocaciones a los recursos contenidos en ellas. El juego es como sigue: supongamos tres funciones func1(); utilA() y utilB(); la primera está en la librería dinámica LibF.dll, las otras dos en LibU.dll. Supongamos que deseamos construir una aplicación, Apli.exe, que debe utilizar dichas funciones. A su vez, los fuentes de la aplicación están en los ficheros Main.cpp yUtils.cpp. Una forma de proceder sería construir una librería de importación, digamos Mi.LIB, con información sobre la localización de las tres funciones externas. Una vez construida, la librería se enlazaría junto con el resto de los módulos para conseguir un ejecutable. Por ejemplo, con el compilador de BC++ podría utilizarse el siguiente comando [1 ]: BCC32 -IC:\BCPP\Include -LC:\BCPP\Lib Main.CPP Utils.CPP Mi.LIB -eApli

Upload: ferbuifo

Post on 27-Oct-2015

44 views

Category:

Documents


0 download

TRANSCRIPT

Programacin C++Adolfo J. Milln

1.4.4b2c Librera de importacin1SinopsisLaslibreras de importacinsonlibreras estticasde terminacin clsica.libo.a, que no contienen cdigo objeto, solo tablas. Cada entrada contiene el nombre de una DLL y la direccin de un recurso exportable dentro de la DLL. Por ejemplo, una funcindllexportde la librera. Generalmente estas direcciones estn en forma de nmeros.Nota:los compiladores C/C++ pensados para escribir aplicaciones que corrern en la plataforma Win32 incorporan algunas de estas libreras con las direcciones de los recursos de la API de Windows (que est constituida por un conjunto de DLLs).Entre las ms frecuentes de estas libreras de importacin estn:IMPORT32.LIB,KERNEL32.LIB,USER32.LIB, yGDI32.LIB.

Estas libreras se enlazan estticamente con la aplicacin que debe utilizar los recursos de la DLL, de forma que el cargador del ejecutable (que debe cargar tambin las libreras) puede resolver las invocaciones a los recursos contenidos en ellas. El juego es como sigue:supongamos tres funcionesfunc1();utilA()yutilB(); la primera est en la librera dinmicaLibF.dll, las otras dos enLibU.dll.Supongamos que deseamos construir una aplicacin,Apli.exe, que debe utilizar dichas funciones. A su vez, los fuentes de la aplicacin estn en los ficherosMain.cppyUtils.cpp.Una forma de proceder sera construir una librera de importacin, digamosMi.LIB, con informacin sobre la localizacin de las tres funciones externas. Una vez construida, la librera se enlazara junto con el resto de los mdulos para conseguir un ejecutable. Por ejemplo, con el compilador de BC++ podra utilizarse el siguiente comando [1]:BCC32 -IC:\BCPP\Include -LC:\BCPP\Lib Main.CPP Utils.CPP Mi.LIB -eApli

La construccin de una librera de importacin comoMi.LIBpuede hacerse de varias formas. La ms simple es crearla en el momento de crear la librera, pero tambin puede ser creada posteriormente a partir de la DLL (cuando no se dispone de los fuentes) mediante herramientas especiales. Por ejemplo, en Borland C++, mediante una utilidad denominadaimplib, y en GNU mediante la utilidaddlltool, que suele estar incluida junto con las "binutils" del compilador.2UtilidadimpdefEl compilador Borland C++ dispone de la utilidadIMPDEFque permite obtener un fichero.DEFde definicin a partir de una librera .DLL;este fichero contiene una seccinEXPORTScon los nombres de todos los recursos exportables de la librera.Nota: El nombre de esta utilidad es acrnimo de "Import Definition", ya que se trata de un manejador de ficheros de definicin .DEF.2.1 SintaxisIMPDEF FicheroDestino.DEF NombreLibreria.DLL2.2 ComentarioEsta orden crea un fichero de definicin de nombreFicheroDestino.DEFa partir del ficheroNombreLibreria.DLL.El fichero .DEF tiene el siguiente aspecto:LIBRARY NombreLibreriaDESCRIPTION 'Descripcion'EXPORTS Nombre_de_funcion_exportable @Ordinal . . . Nombre_de_funcion_exportable @OrdinalCon el significado siguiente:NombreLibreriaes el nombre que aparece en la variableNAMEde la seccin de cabecera de la librera analizada (verFichero de definicin1.4.4a).Descripciones el valor de la seccinDESCRIPTIONsi la librera DLL fue enlazada utilizando un fichero de definicin .DEF que inclua una sentenciaDESCRIPTION.Nombre_de_funcion_exportable Es el nombre de cada funcin exportable de la librera analizada.Ordinales un entero que expresa el orden de dicha funcin.La utilidad acepta los siguientes comandos de ejecucin:-aAade un guin bajo '_' al nombre de las funciones declaradascdeclpara compatibilidad con las libreras de Microsoft.

-hAade algunas indicaciones extra

2.3Ejemplo:Para aplicar la utilidadIMPDEFa la libreraplanetsB.dllconstruida en el ejemplo 3.2 de la pgina anterior (1.4.4b2a), se utilizara el siguiente comando:IMPDEF planetsB.DEF palentsB.DLLObtenindose un ficheroplanetsB.DEFcon el siguiente contenido:LIBRARY PLANETSB.DLL

EXPORTS ___CPPdebugHook @4 ; ___CPPdebugHook _showEarth @3 ; _showEarth _showMercury @1 ; _showMercury _showVenus @2 ; _showVenus3UtilidadimplibEl compilador Borland C++ dispone de la utilidadIMPLIBque permite crearlibreras de importacina partir de una o varias DLLs y/o ficheros de definicin .DEF (1.4.4a).3.1 SintaxisIMPLIB Opciones LibName [ DefFiles... | DLLs... ] [@ResponseFile]

Opcioneses una lista de uno o ms comandos opcionales, que pueden ser los siguientes:-aAade un guin bajo '_' al nombre de las funciones declaradascdecl(4.4.6a) para compatibilidad con las libreras de Microsoft.

-cAvisos para los smbolos sensibles a maysculas/minsculas ("Case sensitive")

-fForzar importacin por nombre

-wNo indicar mensajes de aviso

LibNamees el nombre de la librera de importacin que se crear.DefFileses una lista de uno o varios ficheros de definicin .DEF ralativos a la/s libreras utilizadas.DLLses una lista de una o varias libreras dinmicas cuya librera de importacin se pretende crear (no tienen que ser necesariamente de terminacin .DLL, pueden ser .EXE, .DRV, etc).ResponseFilees unalista de respuesta("Response file"). Se trata de un fichero de texto plano (ASCII) que contiene una lista de los ficheros .DEF y DLLs que se quieren procesar. Puede ser til cuando esta lista es muy numerosa, de forma que no es necesario escribir una lnea de comando muy larga. Los nombres de ficheros de la lista deben ir separados por espacios o nueva lnea NL (ASCII 102.2.1a).En la lnea de comando el nombre de la lista de respuesta debe ir precedido del carcter arroba '@'. Por ejemplo:IMPLIB -w LibPrincipal.LIB @ResFiPr.txt3.2Ejemplo:Para obtener la librera de importacinplanetsB.liba partir de la DLLplanetsB.dllconstruida en el ejemplo de construccin de una librera dinmica con Borland C++ 5.5 Make (1.4.4b2a), se utiliz el comando: implib -c planetsB.lib planetsB.dll4UtilidaddlltoolEsta utilidad acompaa a las "binutils" del compilador GNU gcc. Es utilizada para crear los ficheros necesarios para construir y usar DLLs. La utilidad solo se incluye en los paquetes destinados a soportar DLLs (los destinados a correr en las plataformas Windows de MS). En lo que sigue, nos referimos adlltool.exe, la versin que acompaa al compilador GNU c++ de MinGW (ver recuadro en1.4.0a1).La utilidaddlltoolpuede ser utilizada de muchas formas; a continuacin incluimos un ejemplo de la ms usual: cuando tenemos una librera estticasomelib.dllde la que no son accesibles los fuentes y que se resiste a compilar con alguna de nuestras aplicaciones que la necesita (quizs por estar construida con un compilador distinto del que utilizamos -el mencionado GNU c++ de MinGW para Windows-). En estos casos la solucin puede consistir en compilar nuestra aplicacin "con" ("against" en la literatura inglesa) una librera de importacinsomelib.aconstruida a partir de la mencionada DLL con ayuda dedlltool.Para abreviar la exposicin, utilizaremos las libreras y aplicaciones de ejemplos anteriores. En concreto, los incluidos en los captulos "Construir una DLL" (1.4.4b2a) y "Usar una DLL" (1.4.4b2b). Como resumen, recordemos que se construy una DLL con dos compiladores: GNU c++ y BC++ (Borland C++ 5.5). A continuacin se construy una aplicacin que utiliza las citadas libreras. La aplicacin se construye tambin con ambos compiladores y en sus dos versiones de enlazado para cada caso, implcito y explcito.El resumen de ficheros obtenidos es el siguiente:FicheroCompiladortamao BytesDescripcin

planetsG.dllGNU gcc483.328Librera dinmica

planetsB.dllBorland C++8.192Librera dinmica

planetsE.exeGNU gcc16.384Usa planetsG.dll con enlazado implcito

planetsD.exeGNU gcc479.232Usa planetsG.dll con enlazado explcito

planetsE.exeBorland C++8.192Usa planetsB.dll con enlazado implcito

planetsD.exeBorland C++8.192Usa planetsB.dll con enlazado explcito

Suponemos que no disponemos de la versin GNU de la librera (planetsG.dll) y necesitamos utilizar la versin BC++ disponible (planetsB.dll) para construir un ejecutable que usar enlazado explcito con la citada librera. Para ello, modificamos convenientemente el makefilemakefilE.gnu(1.4.4b2b):# MakefilE.gnu (modificado) Uso de librera Borland planetsB.dll# crear aplicacin planetsE.exe usando librera dinmica con enlazado esttico

LIBS = -L"C:/DEV-CPP/lib"CXXFLAGS = -I"C:/DEV-CPP/lib/gcc/mingw32/3.4.2/include" \ -I"C:/DEV-CPP/include/c++/3.4.2/backward" \ -I"C:/DEV-CPP/include/c++/3.4.2/mingw32" \ -I"C:/DEV-CPP/include/c++/3.4.2" -I"C:/DEV-CPP/include"

planetsE.exe: mainE.o g++ mainE.o -o "planetsE.exe" $(LIBS) dlibs/planetsB.dll

mainE.o: mainE.cpp g++ -c mainE.cpp -o mainE.o $(CXXFLAGS)La invocacin de este makefile produce los siguientes errores:mainE.o(.text+0x2b):mainE.cpp: undefined reference to `_imp__showMercury'mainE.o(.text+0x32):mainE.cpp: undefined reference to `_imp__showVenus'mainE.o(.text+0x39):mainE.cpp: undefined reference to `_imp__showEarth'lo que indica que la versin "tal cual" de la DLL no se entiende bin con nuestro compilador GNU g++. Para resolver el problema, crearemos una librera de importacinplanetsB.aa partir deplanetsB.dlly compilaremos con ella. El makefile a utilizar ser idntico al anterior, pero modificando adecuadamente el comando de la primera regla:planetsE.exe: mainE.o g++ mainE.o -o "planetsE.exe" $(LIBS) dlibs/planetsB.aPara construir la librera condlltool, primero construimos un fichero de definicinplanets.defrelacionando en su apartadoEXPORTSlos identificadores que nos dieron error en la compilacin anterior:LIBRARY PLANETSB.DLLEXPORTSshowMercuryshowVenusshowEarthA continuacin invocamosdlltoolcon el siguiente comando:dlltool -U -d planets.def -l planetsB.aEl resultado es la librera solicitadaplanetsB.a, con lo que ya podemos invocarse el makefile para obtener la aplicacinplanetsE.exeque funciona con la libreraplanetsB.dllde Borland.Nota: el tamao del ejecutable es de 20.480 bytes frente a los 16.384 del obtenido utilizando la DLL de GNU. Ver detalles adicionales enwww.mingw.org En el manual de las binutils GNU puede encontrarse la informacin oficial sobre la utilidaddlltool, que acompaa a los binarios de la dististribucin MinGW.

1.4.4b2d Librera de tipos1 SinopsisLa tecnologa de software evoluciona hacia sistemas interconectados. El tratamiento de la informacin ha ganado en complejidad, imponindose una arquitecturamodular(de componentes) ytransaccional; dos conceptos clave, junto con los decliente/servidor, en la nueva arquitectura de software. Las aplicaciones se basan en componentes, objetos que interactan con otros conjuntos de objetos, del Sistema Operativo o de otras aplicaciones, locales o remotas.A este respecto, los Sistemas Windows han seguido un modelo denominadoCOM(Component Object Model). Un modelo de software cliente/servidor que permite la interaccin entre aplicaciones [1]. El punto importante de esta tecnologa es que permite la comunicacin entre clientes y servidores mediante interfaces normalizadas.En realidadCOMnaci por la necesidad de un mecanismo que permitiese que un elemento de software ofrecieraserviciosa otro. Esto supone que una aplicacin (cliente) pueda manipular objetos implementados en otra aplicacin distinta (servidor) y/o "exponer" objetos propios, de forma que otras aplicaciones puedan manipularlos. Observe que no es preciso que ambas aplicaciones estn escritas en el mismo lenguaje. De hecho, los objetosCOMpueden escribirse en cualquier lenguaje (Java, C++, Pascal etc.) e implementarse en sus propios ejecutables o bajo la forma de libreras .DLL. A un cliente que est utilizando un objetoCOMle es indiferente en que lenguaje se ha escrito o como est implementado, si se est ejecutando en una .DLL o en un proceso separado.

En la nomenclatura Windows estas manipulaciones de objetos de otras aplicaciones se denomina "automatizacin" (formalmente automatizacin OLE), y los objetos de cualquier aplicacin (objetoservidor) puede ser manipulada siempre que exponga una interfaz adecuada (propiedades y mtodos) que puedan ser accedidas desde otras aplicaciones (losclientes).Los clientes "automatizados" pueden ser locales o remotos (incluso en una mquina accesible en una red). Muchas aplicaciones comerciales, incluyendo algunas del propio Microsoft como Excel o Word disponen de esta interfaz, de forma que gran parte de su funcionalidad puede ser automatizada (monitorizada) desde otras aplicaciones.Losclientesdeben disponer de informacin sobre la interfaz del objetoservidorpara poder manipularlo. Esta informacin se concreta en conocer el tipo de datos de las propiedades, as como valores devueltos y argumentos utilizados por los mtodos. Si queremos que un cliente tenga estas habilidades, toda esta informacin (del servidor) debe ser enlazada con l durante su construccin. Esto puede hacerse de varias formas, pero la ms adecuada es crear unalibrera de tipos.Laslibreras de tipos, son un tipo especial delibrera de importacin(esttica), que se enlaza con elclientey le proporciona informacin sobre la forma de acceder a la interfaz delservidor(en realidad informan sobre la forma pasar punteros de modo local o remoto -a travs de redes- a losservidores).Nota: se utiliza el trminolibrera de tiposcuando el objeto descrito en la librera no es una librera dinmica normal, sino un control ActiveX, un servidor OLE, un servidor COM.1.4.4b2e Carga retrasada1 SinopsisLacarga retrasada("delay load") es una opcin de compilacin utilizable en la compilacin de ejecutables que deban utilizar recursos situados en libreras dinmicas. Resulta de utilidad con libreras que se usan raramente en un programa pero que son muy voluminosas, y por tanto, tienen un gran coste de carga.Las DLLs de carga retrasada no son cargadas e inicializadas hasta que el programa alcanza un punto en que se intenta acceder a la librera. De lo anterior se deduce que se trata de un caso particular de enlazado explcito (dinmico) con el ejecutable que las utiliza.Ejemplo[2]:ilink32 /dMyDataBase.dll c0x32 x ,x,,import32 cw32mt MyDataBase.lib

En este caso, la opcin/dhace que la libreraMyDataBasesolo sea cargada cuando realmente se utilice alguno de sus recursos.Nota: La RTL del compilador BC++ dispone de utilidades que permiten al usuario cargar a voluntad estas libreras para depurar errores de carga, e incluso suplantar el sistema de retraso si se desea.2 EmpleoLa opcin de carga retrasada puede ser una opcin a considerar si: Hay posibilidad de que un recurso no llegue a ser utilizado por el programa. Por ejemplo, solo se utiliza en determinadas condiciones que pueden no llegar a ocurrir. Un recurso cuya carga es costosa (en trmino de tiempo e inicializacin) solo se requiere hasta un tiempo despus de iniciado el programa.De esta forma, al costo de inicio del programa no se le suma el de la DLL.La impresin del usuario es que el programa se inicia ms rpidamente.3 RestriccionesEl compilador BC++nopermite usar el dispositivo de carga retrasada en los siguientes casos: Una librera que contenga referencias a otros datos que deban ser tambin importados. La libreraKERNEL32.DLL(una librera de la API de Windows). La libreraRTLDLL, ya que esta librera contiene precisamente las rutinas que soportan la carga retrasada.4 Descargar una librera de carga retrasada.Despues que una DLL ha sido cargada con retraso, puede ser conveniente descargarla manualmente.Para ello, tanto BC++ como MSVC disponen de una funcin especfica de librera,__FUnloadDelayLoadedDLL, que puede descargar la librera y resetear el mecanismo de carga por si fuese necesaria de nuevo en el futuro.4.1 Sintaxis#include BOOL WINAPI __FUnloadDelayLoadedDLL(LPCSTR szDll);

szDlles un puntero al nombre de la librera a descargar o un valor nulo (NULL) para descargar todas las libreras de carga retrasada.4.2 DescripcinComo puede verse, esta funcin devuelve unbool(3.2.1b). En caso de xito el valor devuelto es cierto (true) en caso contrario devuelve falso (false).4.3 ComentarioDeben observarse precauciones especiales al descargar libreras de carga retrasada en una aplicacin multihebra (1.7). Pueden presentarse problemas si una de las tareas obtiene la direccin de una funcin de librera al mismo tiempo que otra tarea procede a la descarga de la DLL correspondiente.

1.4.5 Depuracin"Software is a conversation, between the software developer and the user. But for that conversation to happen requires a lot of work beyond the software development. It takes marketing, yes, but also sales, and public relations, and an office, and a network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks". Joel Spolsky. "The Development Abstraction Layer".www.joelonsoftware.com.1 GeneralidadesLadepuracinest estrechamente relacionada con el concepto decalidad.En un sentido amplio, depurar un programa significa librarlo de errores e inconvenientes ms o menos graves, que con frecuencia es un proceso mucho mas costoso y arduo de lo que pudiera parecer a primera vista, en especial en programas grandes y complejos. Sin embargo, es imprescindible si queremos ofrecer al pblico un producto con un mnimo de calidad.Es interesante comprobar como la posicin comercial de las grandes empresas de software ha evolucionado hasta una posicin que podra considerarse envidiable y casi nica, en relacin con los productos producidos por el resto de la industria. Los que manejamos habitualmente software de cualquier tipo, desde la ms humilde utilidad shareware [1] hasta los propios sistemas operativos, estamos acostumbrados a ver durante el proceso de instalacin clusulas en las que se anuncia que el producto se vende "Tal cual" ("As is"); sin ningn tipo de garanta o de responsabilidad que pudiera derivarse de su posible mal funcionamiento. Es cierto que el software tiene unas caractersticas muy especiales y que se podra decir mucho al respecto, pero no es menos cierto que habitualmente aceptamos condiciones que no le permitiramos al fabricante que nos vende un automvil, un par de zapatos o una lata de conserva por ejemplo.Podemos observar como incluso productos software muy conocidos y de gran consumo, producidos por compaas muy poderosas [4], son lanzados a veces sin un proceso de depuracin adecuado; motivado la mayora de las veces por la excesiva presin de su propia maquinaria de mrketing, que las fuerza a lanzar nuevos productos y versiones a un ritmo desenfrenado.En Junio de 2002, el NIST ("National Institute of Standards and Technology"), organismo dependiente del Gobierno USA publicaba un informe titulado "The Economic Impacts of Inadequate Infrastructure for Software Testing", en el que se analiza la repercusin econmica debida a los defectos del software en dos sectores econmicos del pas: Servicios financieros, e industria de fabricacin de medios de transporte. El resultado es que solo en estos sectores, el coste de los errores (bugs) derivados de la incorrecta depuracin del software asciende a unos 60.000 millones de dlares anuales [5].

2 DepuracinEn general la depuracin de un programa se completa en tres fases; es un proceso en el que el producto se va acercando a la perfeccin (estar libre de errores e inconvenientes graves) mediante una serie de transformaciones sucesivas que responden al esquema de la figura.

En una primera fase, cuando ya el programa est prcticamente terminado, se somete a pruebas que podramos llamar "de laboratorio" para comprobar que todo marcha segn lo esperado y sin errores [2]. Son pruebas que realiza el propio programador antes de dar a conocer el producto. Estas versiones se suelen denominaralfay corresponden a un punto en que el programa todava est en fase de gestacin. En una versin alfa son de esperar todo tipo de errores y "cuelgues".En una segunda fase, cuando el programador cree que su producto ya est suficientemente presentable y l no consigue encontrar ms errores aparentes (o los ya conocidos estn en proceso de depuracin), se procede a la distribucin del producto a una serie de probadores seleccionados ("beta testers"). Son las denominadas versionesbeta, que aunque con errores espordicos, pueden tener un comportamiento ms o menos aceptable.Finalmente, en una tercera fase, con la informacin, opiniones y sugerencias de los "beta testers", se procede a lanzar la primera versin pblica v 1.0 del producto ("Release"), tambin denominadas versionesgamma. A partir de aqu, lo normal es que se vayan recogiendo las sugerencias, cuestiones y posibles errores que hayan pasado inadvertidos en las pruebas beta y sean reportados por los usuarios. Las soluciones a estos problemas, junto con las mejoras que se vayan incorporando, son implementados en versiones sucesivas. Generalmente a partir de la versin 2.0 el producto se consideraestable.3 El cuaderno de bitcoraEs frecuente que los programadores cuidadosos mantengan una especie de registro histrico o cuaderno de bitcora donde se recoge la evolucin del programa. Puede tratarse de un simple fichero de texto plano con cualquier nombre alusivo: Cambios.txt; Historia.txt; Versiones.txt [6], Etc. En l se recoge la informacin que se estima pertinente. Por ejemplo, las fechas de publicacin de las diversas versiones; las mejoras introducidas respecto a las anteriores, y sobre todo los errores ("bugs") corregidos. Este fichero suele acompaar a cada nueva versin, pero lo mejor es darles la mxima publicidad entre los usuarios potenciales y actuales. Los primeros, porque se pueden hacer una idea de la vitalidad del producto (una historia larga de actualizaciones regulares y frecuentes es buena seal). A los usuarios actuales porque les permite evaluar si les merece la pena o no el proceso de actualizacin a las nuevas versiones.En lo que respecta a este captulo, nos referiremos exclusivamente a la depuracin de versiones alfa, en las que los procesos de construccin del ejecutable suelen incluir los mecanismos de depuracin, que posteriormente se omiten en las versiones de campo.Nota: Llegados a este punto, aconsejamos al lector novel saltarse por ahora el resto del captulo y seguir con las siguientes secciones. Para lo que sigue es necesario conocer previamente los captulos dedicados a: Tratamiento de Excepciones (1.6) y los Operadores de Preproceso (4.9.10).4El depuradorComo se ha sealado anteriormente (1.4), los compiladores tienen una opcin que permite incluir o no informacin adicional de depuracin en el ejecutable. Esta informacin adicional consiste bsicamente en la inclusin del nmero de lnea (del cdigo fuente) de cada sentencia, aunque tambin se pueden tomar otras medidas. Por ejemplo, tratar todas las funciones como si fuesen normales, no realizndose en estos casos sustitucionesinline(4.4.6b).Nota: en el caso del compilador Borland C++ 5.5, la opcin correspondiente es el comando-v, que est conectado (ON) por defecto (4.4.6b). El compilador GNU gcc utiliza la opcin-gpara este propsito. No olvide que la presencia de la informacin de depuracin produce ungran aumentode tamao del ejecutable, por lo que solo debe utilizarse cuando verdaderamente sea necesaria.

Los entornos de desarrollo C++ actuales incluyen potentes depuradores con los que es posible controlar prcticamente todos los aspectos de ejecucin de versiones alfa. Su manejo depende naturalmente de cada caso concreto, pero en general permiten inspeccionar el estado de llamadas de la pila, lo que significa controlar la "traza" de la ejecucin. De esta forma es posible conocer el camino que ha seguido la ejecucin hasta llegar a un punto concreto (que funciones han sido invocadas y cual es el valor de las variables). Por ejemplo, cuantas veces se ha invocado a s misma una funcin recursiva y que valores tienen sus variables en cada una de las instancias; el valor de las variables globales, locales, automticas y estticas.Las opciones anteriores son las que podramos llamar mnimas. Por supuesto las versiones ms avanzadas de los productos punteros permiten hurgar ms cmoda y profundamente en las entraas del ejecutable. Por ejemplo, depurar funciones miembro y aplicaciones multihebra; controlar la ejecucin paso a paso; a nivel de instrucciones mquina (ensamblador) o a nivel de sentencia de nuestro cdigo fuente, as como instalar puntos de control ("break points") en el ejecutable. Se trata de instrucciones especficas instaladas a la entrada de las zonas de cdigo donde sospechamos que se presentan los problemas. Esto nos permite correr el programa a velocidad normal, pero al llegar a dichos puntos, es invocado automticamente el depurador que nos muestra todas sus herramientas [3]; entonces se pueden realizar las comprobaciones oportunas, y si todo est correcto, volver a modo ejecucin normal hasta que se alcanza el prximo punto de control (en los ejemplos que siguen aprenderemos a instalar en nuestro cdigo puntos de control rudimentarios sin necesidad de utilizar ningn depurador).Para cuando estas posibilidades no bastan, o sencillamente no se dispone de ellas, existen una serie de trucos y tcnicas generales que facilitan la depuracin. El proceso ms general y socorrido consiste en incluir en el cdigo una serie de puntos testigo ("flags") con salidas provisionales que nos informan que el programa ha pasado por el punto sin novedad y los valores de las variables sospechosas de mal funcionamiento.Ejemplo 1:Una forma sencilla de implementar estos semforos puede ser utilizar undefine(4.9.10b). Como ejemplo construimos un programa que muestre el paso por diversos puntos:#include #define testigo(punto) cout