C más o menos − Programación en C++

Año nuevo

2011-12-23T16:12:00.000-03:00

Bueno, este año fue poco productivo en este blog. El próximo no prometo mucho más, pero espero mejorar. Dejo un par de links que agregué en la sidebar:

Pre-defined C/C++ Compiler Macros: Si alguna vez tenemos que detectar la versión de un compilador o en qué plataformas estamos, estas macros pueden ayudarnos a escribir código portable.
C++ Reference Wiki: Una wiki con referencia sobre C++ y C++11

Los próximos años pueden llegar a ser los mejores años de C++. Con clang avanzando sobre gcc, es probable que aparezcan herramientas muy importantes para ayudar a programar en C++. Aquí les dejo un video:

¡Feliz año nuevo!

Código C++ moderno

2011-09-21T01:03:00.001-03:00

Una excelente charla de Herb Sutter (en inglés) introduciendo algunas de las novedades del nuevo estándar C++11 y sobre cómo escribir código en C++ aprovechando todo el conocimiento acumulado en estos años (si nunca leíste C++ Coding Standards de Herb Sutter y Andrei Alexandrescu, compralo):

http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T

Los puntos tratados que no podes dejar pasar por alto:

El nuevo significado de la palabra auto para inferir tipos automáticamente.
La nueva sintaxis de lambdas para definir functors en línea y usarlos en algoritmos estándares (ej: for_each()).
Exception safety y heap lifetime con smart pointers, los cuales ya tenemos varios posts en este mismo blog sobre el concepto de smart pointers y RAII.
Nuevos contenedores de tipo hash table.
Move semantics que evita la creación y destrucción de objetos temporales innecesarias (ej: al retornar por valor).
Varios pequeños nuevos coding standards de C++11: funciones begin()/end(), override explícito, idioma pimpl con unique_ptr<>, etc.

En futuros posts voy a dedicar algo de tiempo en introducir estos temas y explicar por qué nacieron cada una de estas modificaciones en el nuevo estándar de C++.

Cola de prioridades (STL priority_queue)

2011-03-08T13:09:00.001-03:00

La cola de prioridades es una estructura de datos que se puede visualizar como una bolsa, donde podemos ir metiendo elementos uno atrás del otro, pero sólo los podemos retirar según un criterio de prioridad. Por ejemplo, en el caso de un ladrón obsesivo-compulsivo, podría robar un banco cargando bolsas de dinero sin ningún criterio, y al vaciarla podría retirar los billetes según su valor (primero los de $100, luego los de $50, etc.).

Otro ejemplo, imaginemos que tenemos un barco:

#include <queue>
#include <list>

using namespace std;

class Barco {
public:
  void subirPasajero(const Pasajero& pasajero);
  void abandonarBarco(list<Pasajero>& pasajerosEnOrden);

private:
  priority_queue<Pasajero> pasajeros_;
};

La función subirPasajero() debe agregar un pasajero al barco, y abandonarBarco() debe sacar todos los pasajeros del barco y colocarlos (por orden de prioridad) en la lista que se recibe como argumento:

void Barco::subirPasajero(const Pasajero& pasajero)
{
  pasajeros_.push(pasajero);
}

void Barco::abandonarBarco(list<Pasajero>& pasajerosEnOrden)
{
  while (!pasajeros_.empty()) {
    pasajerosEnOrden.push_back(pasajeros_.top());
    pasajeros_.pop();
  }
}

Tenga en cuenta que la función miembro pop() de las colas en C++ (queue, priority_queue, etc.) no retornan el valor extraído. Esto es así para evitar crear copias de los objetos dentro de la cola. De este modo la función top() devuelve una referencia al elemento mismo que se encuentra en la cola, y pop() lo remueve sin devolver nada. Así nos evitamos de crear copias temporales de la instancia removida.

Para poder usar la priority_queue sobre un tipo de dato propio (como Pasajero), debemos ofrecer una implementación del operator<() para comparar distintas instancias de nuestro tipo de dato (este operador se utiliza para saber qué elemento debe salir último de la cola, es decir, el menor elemento tiene menor prioridad):

enum Prioridad { Capitan, Hombre, Mujer, Ninio };

class Pasajero {
public:
  Pasajero(Prioridad p) : prioridad_(p) { }

  bool operator<(const Pasajero& otro) const {
    return prioridad_ < otro.prioridad_;
  }

  Prioridad prioridad() const { return prioridad_; }

private:
  Prioridad prioridad_;
};

De este modo, el capitán tiene prioridad 0 y es tomado en cuenta como el de menor prioridad para abandonar el barco. Los pasajeros que mayor prioridad tienen de abandonar el barco son las mujeres y los niños. En este caso podrían tener igual prioridad, no tendría mucho sentido salvar a todos los niños sin sus respectivas madres.

Ahora podemos crear un ejemplo:

#include <iostream>

using namespace std;

int main()
{
  Barco titanic;
  titanic.subirPasajero(Pasajero(Capitan));
  titanic.subirPasajero(Pasajero(Mujer));
  titanic.subirPasajero(Pasajero(Hombre));
  titanic.subirPasajero(Pasajero(Mujer));
  titanic.subirPasajero(Pasajero(Ninio));
  titanic.subirPasajero(Pasajero(Hombre));
  titanic.subirPasajero(Pasajero(Ninio));
  // ...

  list<Pasajero> pasajeros;
  titanic.abandonarBarco(pasajeros);
  
  for (list<Pasajero>::iterator it = pasajeros.begin(),
         end = pasajeros.end(); it != end; ++it) {
    cout << it->prioridad() << "\n";
  }
  
  return 0;
}

El anterior ejemplo imprime:

Lo que significa que, sin importar el orden en el cual agregamos los pasajeros, primero extraemos los niños, luego las mujeres, los hombres, y finalmente el capitán.

Más información:
http://www.cplusplus.com/reference/stl/priority_queue/
http://en.wikipedia.org/wiki/Priority_queue

Iostream - Redireccionar clog para "loguear" en un archivo

2010-09-18T16:32:00.000-03:00

La iostream es la librería de entrada y salida de C++. Existen algunos streams estándares de salida: std::cout, std::cerr y std::clog. El primero apunta a la consola, y los dos últimos... también. Las diferencias son estas:

cout apunta a la salida estándar STDOUT (texto de resultado esperado de un programa);
cerr y clog apuntan a STDERR (salida de errores y cualquier otra porquería).

Aunque a primera vista todo el texto se envía a la consola, uno puede redireccionar la salida a otros lados. Por ejemplo, imaginemos que tenemos el siguiente programa test.exe:

#include <iostream>

using namespace std;

int main()
{
  cout << "A\n";
  cerr << "B\n";
  clog << "C\n";
  return 0;
}

Al ejecutarlo, obtenemos por pantalla las tres líneas:

test.exe [ENTER]
A
B
C

Pero resulta interesante saber que podemos redireccionar el STDOUT a un archivo y el STDERR a otro. Ejemplo:

test.exe 1>stdout.txt 2>stderr.txt

¿Qué demonios es 1 y 2? Los archivos tienen un descriptor que los identifica, 1 es para la STDOUT, y 2 para STDERR. El signo mayor (>) significa que "quiero redireccionar toda la salida de texto que vaya para este descriptor a este archivo". En el anterior ejemplo logramos obtener dos archivos distintos, stdout.txt que contiene una línea (A), y stderr.txt que contiene dos líneas (B y C).

Generalmente, los logs van a un archivo, no a la pantalla. Aunque por defecto clog mande todo a STDERR, resulta útil redireccionar este stream a un archivo propio (por ejemplo, test.log). De esta forma, podemos hacer uso de clog para "loguear" todo lo que nuestro programa hace.

¿Cómo se redirecciona clog? Básicamente los streams de C++ tienen un streambuf asociado, y éste es el realmente encargado de leer y escribir datos (en la pantalla, en un archivo, en un string en memoria, etc.). Por lo tanto, si creamos un fstream y le colocamos su propio streambuf a clog, podemos usar clog como un "alias" del fstream original (clog va a estar compartiendo el mismo streambuf que el fstream). El código resultante es bastante sencillo:

#include <iostream>
#include <fstream>

using namespace std;

int main()
{
  // Creamos un archivo de salida para logging.
  ofstream test_log;
  test_log.open("test.log");

  // Obtenemos el streambuf actual de clog (esto
  // lo usaremos luego para restaurar el streambuf
  // a su valor original, por si las moscas).
  streambuf* old_rdbuf = clog.rdbuf();

  // Reemplazamos el streambuf de clog con el del archivo.
  // Ahora ambos streams utilizarán el mismo streambuf (es
  // decir, escriben en el archivo test.log).
  clog.rdbuf(test_log.rdbuf());

  // Hacemos lo mismo que el ejemplo original.
  cout << "A\n";
  cerr << "B\n";
  clog << "C\n";
  
  // Restauramos el viejo streambuf de clog.
  clog.rdbuf(old_rdbuf);

  // Cerramos el archivo.
  test_log.close();
  return 0;
}

Y listo, ahora podemos hacer lo mismo que antes:

test.exe 1>stdout.txt 2>stderr.txt

Con lo cual obtenemos tres archivos:

stdout.txt con la línea A.
stderr.txt con la línea B.
test.log con la línea C.

Miembros virtuales

2010-08-30T20:45:00.003-03:00

Una función miembro virtual tiene la característica de poder ser sobrecargada por subclases para agregar un comportamiento propio. Pero existen dos lugares en donde las funciones virtuales toman un comportamiento especial: en los constructores y los destructores.

Veamos el siguiente ejemplo:

#include <iostream>

using namespace std;

class Lugar {
public:
  Lugar() {                     // El lugar es creado
    creacion();                 // Llamamos a la función virtual
  }
  virtual ~Lugar() {            // El lugar es destruido
    destruccion();              // Llamamos a la función virtual
  }
protected:
  virtual void creacion()    { }
  virtual void destruccion() { }
};

class Universo : public Lugar {
protected:
  void creacion()    { cout << "Big Bang\n"; }
  void destruccion() { cout << "Big Crunch\n"; }
};

int main()
{
  Universo i_am_god;  // ¿Qué imprime este programa?
  return 0;
}

La idea de todo método virtual es poder proporcionar puntos de extensión a las clases derivadas. En este caso, ¿Lugar::creacion funciona como punto de extensión para clases derivadas? La respuesta es: no. El anterior programa no imprime nada.

Aunque creamos una instancia de Universo, ni el método Universo::creacion ni Universo::destruccion se llamaron. ¿A qué se debe esto? Imaginemos que al crear un Universo, primero debemos crear un Lugar en su totalidad, para luego comenzar a crear el universo. Es por eso que si llamamos a creacion mientras estamos construyendo el Lugar, no podemos alcanzar el método Universo::creacion ya que el Universo todavía no comenzó a ser construido (no tiene un Lugar completamente construido donde existir).

La secuencia correcta es:

Alojamos un cacho de memoria suficiente como para que entre el universo.
Algo así como hacer un: this = malloc(sizeof(Universo)) en C.
Construimos el Lugar usando la memoria recién obtenida como puntero this.
Luego construimos el Universo.
Y recién ahí somos capaces de llamar a Universo::creacion y asegurarnos que estaremos usando el método especializado de la subclase.

¿Puedo llamar a creacion dentro del constructor de Universo? La respuesta es sí, todo es posible. ¿Es correcto? Mmmhh, depende, si alguien hace una subclase de Universo y sobreescribe creacion, nuevamente estará en el mismo problema que estamos mostrando aquí.

¿Por qué en el destructor de Lugar no llama a Universo::destruccion? Porque el Universo ya está destruido (¿cruncheado?) para cuando llegamos al destructor del Lugar.

¿Cómo lo soluciono? Usar puntos de extensión en los constructores y destructores presentan más problemas que ventajas. La solución es no usarlos. Solución (obvia):

#include <iostream>

using namespace std;

class Lugar {
public:
  Lugar() { }
  virtual ~Lugar() { }
};

class Universo : public Lugar {
public:
  Universo()  { cout << "Big Bang\n"; }
  ~Universo() { cout << "Big Crunch\n"; }
};

int main()
{
  Universo i_am_god;
  return 0;
}

En un próximo post voy a dar un ejemplo más complejo donde esto no sirve.

¿Y qué sucede si llamo una función miembro abstracta en el constructor o destructor? Es el desastre total. Completamente ilegal. Imposible. Una violación absoluta a la razón y el sentido común. Imagine este código:

#include <iostream>

using namespace std;

class Lugar {
public:
  Lugar() { creacion(); }        // Ja llamo a creacion()
protected:
  virtual void creacion() = 0;   // Jaja y no lo defino ;)
};

class Universo : public Lugar {
protected:
  void creacion() { }            // Jajaja sólo puede llamarme a mí!
};

int main()
{
  Universo i_am_god_x2;
  return 0;
}

Al compilar este código con gcc obtenemos un warning porque estamos llamando un método abstractor en el constructor, y un error de enlace al crear el ejecutable ya que Lugar::creacion no está definido:

test.cpp: In constructor 'Lugar::Lugar()':
test.cpp:7:22: warning: abstract virtual 'virtual void Lugar::creacion()' called from constructor
C:\temp\ccstr9Hr.o:test.cpp:(.text$_ZN5LugarC2Ev[Lugar::Lugar()]+0x16): undefined reference to `Lugar::creacion()'
collect2: ld returned 1 exit status

Aunque dijimos explícitamente que Lugar::creacion() es abstracto (=0), eso no significa que no debamos definirlo en este caso tan particular.

Referencias:
Sutter, Herb & Alexandrescu, Andrei (2004). Item 49: Avoid calling virtual functions in constructors and destructors. C++ Coding Standards: 101 Rules, Guidelines, and Best Practices. Boston, MA: Addison-Wesley Professional, (ISBN 0321113586).

Descargar MinGW con gcc 4.5 automáticamente

2010-06-06T14:35:00.010-03:00

Este post se podría llamar:

¿Cómo instalar MinGW?
¿Cómo instalar y usar gcc 4.5 en Windows?
¿Cómo compilar programas de C o C++ en Windows?
O también, ¿puedo portar MinGW en un pendrive?

Cualquiera de los casos se responde con el siguiente archivo: MinGW-Downloader-0.2.zip.

Los pasos a seguir son los siguientes:

Cree una carpeta donde descomprimir MinGW-Downloader-0.2.zip (por ejemplo, C:\Compilers, o C:\GNU, lo importante es que la carpeta no tenga espacios!)
Descomprima MinGW-Downloader-0.2.zip en esa carpeta
Ejecute el archivo "C:\Compilers\MinGW-Downloader\MinGW-4.5-Downloader.bat"
Espere...
Una vez finalizado deberá ver algunos mensajes en la pantalla diciéndole si tuvo éxito (SUCCESS), inclusive el script intenta compilar un programa en C y otro en C++.
Listo, ya tiene MinGW con gcc 4.5 disponible en su máquina.

Puede usar el script "Run-cmd-with-MinGW-4.5.bat" para ejecutar la línea de comandos de Windows y tener el compilador disponible (gcc, g++, etc.) en la variable PATH. Lo importante es que el proceso de descarga no modifica ninguna variable de entorno suya (PATH), por lo tanto, podría borrar la carpeta "C:\Compilers" y empezar desde cero siempre que así lo desee.

Puede mover la carpeta "C:\Compilers\MinGW-Downloader\MinGW-4.5" a "C:\MinGW-4.5" y borrar "C:\Compilers\MinGW-Downloader" completamente. Si quiere tener el compilador disponible desde cualquier aplicación (por ejemplo, desde un editor de texto o IDE), podría agregar la ruta "C:\MinGW-4.5\bin" a su PATH.

Cabe destacar que la carpeta "MinGW-4.5" ("C:\Compilers\MinGW-Downloader\MinGW-4.5") y el archivo "Run-cmd-with-MinGW-4.5.bat" los puede mover donde usted desee (por ejemplo, llevarlos en un pen drive), sólo tenga en cuenta que para hacer esto los dos tienen que estar en el mismo directorio (e.j. "C:\MinGW-4.5" y "C:\Run-cmd-with-MinGW-4.5.bat").

Shared Pointers de C++0x

2010-05-29T15:59:00.003-03:00

En C usted puede hacer esto:

#include <stdlib.h>

struct Persona { };

int main()
{
  Persona* a = malloc(sizeof(Persona));
  free(a);
  return 0;
}

Un ejemplo equivalente en C++:

class Persona { };

int main()
{
  Persona* a = new Persona();
  delete a;
  return 0;
}

Por cada malloc existe un free (al menos que use reallocs), y por cada new existe un delete (y por cada new[] un delete[]).

¿Existe una forma por la cual C++ se "entere" que ya no quiero usar un puntero? La respuesta es: No, no existe. C++ no tiene un garbage collector. Pero existen clases que pueden ayudarnos, como el viejo y tan poco querido auto_ptr, o los mejorados unique_ptr, shared_ptr y weak_ptr del nuevo estándar de C++0x (o el TR1).

Un shared pointer es una clase que se encarga de guardar un puntero a un objeto (o tipo de dato), y cuenta la cantidad de referencias que se están haciendo a dicho objeto (es decir, la cantidad de shared pointers que apuntan al mismo objeto). El último shared pointer que se destruya (cuando las referencias llegan a cero), será el encargado de borrar el objeto apuntado (mediante un simple delete).

Un ejemplo:

#include <iostream>
#include <memory>  // Aquí debería estar shared_ptr<> (GCC 4.4)

using namespace std;

class Persona {
  int n;

public:
  Persona(int n) : n(n) {
    cout << "Nace la persona " << n << "\n";
  }

  ~Persona() { 
    cout << "Muere la persona " << n << "\n";
  }

  static shared_ptr<Persona> Crear(int n) { 
    return shared_ptr<Persona>(new Persona(n));
  }
};

int main()
{
  shared_ptr<Persona> a(new Persona(1));
  shared_ptr<Persona> b = Persona::Crear(2);
  shared_ptr<Persona> c;

  cout << "--- Aquí ambas personas existen ---\n";

  c = a; // Aquí c apunta a la persona 1
  b = c; // Ahora b apuntará a la persona 1 (la persona 2 muere porque
         // ya no existen referencias a ella)

  cout << "--- Aquí la persona 2 ya no existe ---\n";
  
  return 0;
}        // Aquí muere la persona 1 (a, b, c apuntaban a ella)

La salida del anterior programa es esta:

Nace la persona 1
Nace la persona 2
--- Aquí ambas personas existen ---
Muere la persona 2
--- Aquí la persona 2 ya no existe ---
Muere la persona 1

Como puede ver, en el anterior programa se llama sólo dos veces a "new Persona" y dos veces al destructor ~Persona. No debemos preocuparnos por usar "delete", el shared_ptr<> hace todo por nosotros.

¿Cómo hago para que la clase shared_ptr funcione en VS2008 SP1 Express? Debe definir _HAS_TR1 antes de incluir el archivo <memory>. Ejemplo:

#ifdef _MSC_VER      // Si estamos usando el compilador de Microsoft
  #define _HAS_TR1 1 // Esto hará que se incluyan las clases del TR1 (std::tr1)
#endif

#include <iostream>
#include <memory>

using namespace std;
#ifdef _MSC_VER
  using namespace std::tr1; // para tener shared_ptr<> disponible
#endif

// Resto del ejemplo...

C++0x Final Committee Draft (FCD)

2010-03-31T09:07:00.002-03:00

Ya está disponible el documento N3092, Programming Languages — C++, Final Committee Draft. Este documento es el que más podría corresponder al nuevo estándar ISO de C++ (lo que viene de acá a uno o dos años pueden ser correcciones menores):

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf

Más información acá.

STL string, parseando un número de versión

2010-01-27T20:14:00.004-03:00

En esta ocasión vamos a ver cómo usar la clase std::string para convertir una cadena de caracteres (como "1.2.3") en una clase "Version" que tenga una interfaz simple de utilizar (por ejemplo, que permita comparar versiones).

Los pasos son simples:

tenemos como entrada una cadena de caracteres,
dividimos la cadena según el caracter '.' (punto),
convertimos cada parte a entero,
guardamos cada número entero de forma ordenada en un vector.

El punto 2 es en el cual nos vamos a enfocar más. El código mostrado aquí es a modo de ejemplo, y está lejos de ser el más óptimo.

Antes de comenzar ¿Podemos usar strcmp para comparar dos versiones? No, no podemos. Ejemplo: strcmp("1.9", "1.10") > 0, cuando en realidad la versión 1.9 es menor a 1.10.

Imaginemos que tenemos una cadena:

std::string ver = "1.10.2.3";

La clase std::string tiene la función miembro find, la cual podemos usar para buscar casi cualquier cosa dentro de la cadena. ¿Qué debemos buscar? Los puntos, sabiendo donde está cada punto, podemos ir recortando la cadena en sus distintas partes ("1", "10", "2", y "3"). Buscamos la ubicación del primer punto:

size_t i = ver.find('.');

if (i != std::string::npos)
  std::printf("El punto fue encontrado en la posición %d\n", i);
else
  std::printf("No hay punto en la cadena\n");

Ejecutando el código anterior, deberíamos obtener el mensaje:

El punto fue encontrado en la posición 1

¿Qué es size_t? Es como el tipo "unsigned int", el tipo de dato retornado por el operador sizeof() y utilizado como índice en las funciones de std::string.

¿Qué es std::string::npos? Es el máximo valor posible de un size_t y se utiliza para indicar (en este caso) que la función find falló (no encontró el punto).

Una vez que tenemos la posición del punto, podemos obtener la porción de texto que contiene la primer cifra, para eso usamos la función miembro substr:

std::string primer_cifra = ver.substr(0, i);

Esto significa: che vos, función substr, devolveme el pedazo de cadena de caracteres que va desde el índice 0, y tiene una longitud de i-caracteres.

El proceso puede ser repetido tantas veces como queramos para seguir obteniendo cifras. Por ejemplo, para la siguiente cifra debemos buscar (find) el siguiente punto, pero comenzando desde el que encontramos hace un rato:

i++;     // ir a la posición siguiente del punto '.'
size_t j = ver.find('.', i);

¿Qué es (o hace) el segundo argumento de find? Le indica a la función desde donde debe comenzar a buscar. La primera vez que usamos find este argumento no se especificó, porque por omisión toma el valor 0, es decir, buscar desde el inicio de la cadena.

¿Por qué i++? Porque si comenzáramos a buscar un punto desde i, nos devolvería la misma posición i (porque justamente, en i, está el primer punto que encontramos). Entonces debemos avanzar una posición.

Ahora, debemos recortar la segunda cifra:

std::string segunda_cifra = ver.substr(i, j-i);

La segunda cifra, comienza desde i y tiene una longitud igual a j-i. Para comprender esto, vea la siguiente figura:

De esta forma, ver.substr(i, j-i) nos devuelve la cadena "10". La versión completa del algoritmo puede quedar algo así:

#include <vector>  // Por std::vector
#include <string>  // Por std::string
#include <cstdlib> // Por std::strtol
#include <cstdio>  // Por std::printf

int main()
{
  std::string ver = "1.10.2.3";

  // Vector con cada cifra.
  // Luego del procesamiento esto debería ser = { 1, 10, 2, 3 }
  std::vector<int> cifras;

  size_t i = 0;   // Comenzamos desde i=0
  size_t j = 0;

  // Repetir hasta no llegar al final de la cadena
  while (j != std::string::npos) {
    // Buscar próximo punto
    j = ver.find('.', i);

    std::string cifra;

    // Si se encontró un punto
    if (j != std::string::npos) {
      // Recortamos desde i hasta j
      cifra = ver.substr(i, j-i);

      // El nuevo comienzo para buscar puntos será "j+1"
      i = j+1;
    }
    // Si no se encontró un punto
    else {
      // Recortamos desde "i" hasta el final de la cadena
      cifra = ver.substr(i);
    }

    // Obtener el valor entero de la cifra
    int cifra_int = std::strtol(cifra.c_str(), NULL, 10);

    // Agregar la cifra al vector
    cifras.push_back(cifra_int);
  }

  for (size_t i=0; i<cifras.size(); ++i)
    printf("cifras[%d] = %d\n", i, cifras[i]);

  return 0;
}

La salida del anterior programa es:

cifras[0] = 1
cifras[1] = 10
cifras[2] = 2
cifras[3] = 3

Con este código, podríamos implementar una clase "Version" con la siguiente interfaz:

class Version
{
public:
  Version(const char*);
  Version(const std::string&);

  bool operator==(const Version& u) const;
  bool operator<(const Version& u) const;
  // ...
};

En un próximo post voy a colocar una posible implementación de la clase "Version".

Punteros por ámbito (scoped pointers)

2009-11-06T00:50:00.007-03:00

C++ no tiene un recolector de basura, aunque C++0x le va tomando el gustito, tenemos algunas opciones para liberarnos de liberar memoria, valga la redundancia.

Imaginemos un código como el siguiente:

#include <cstdio>

using namespace std;

class A {
public:
  A()         { printf("A\n");    }
  ~A()        { printf("~A\n");   }
  void hola() { printf("hola\n"); }
};

int main()
{
  A* a = new A;
  a->hola();
  return 0;
}

El anterior programa, por más minimalista que parezca, tiene un memory leak. Aunque los recursos suelen ser liberados por el mismo sistema operativo al finalizar el programa, si el proceso se ejecuta por mucho tiempo (e.j. un servicio que se ejecuta por días, semanas o meses dentro de un servidor), los recursos se van agotando poco a poco hasta que la computadora queda hecha una pasa.

Para arreglar el leak, deberíamos escribir:

int main()
{
  A* a = new A;
  a->hola();
  delete a;
  return 0;
}

¿Cómo hacemos para liberar memoria sin llamar delete nosotros mismos? Podemos crear una clase utilitaria que haga el trabajo por nosotros en su destructor. Por ejemplo, en el siguiente código veremos que el delete es llamado en el destructor de PunteroA:

class PunteroA {
  A* ptr;
public:
  PunteroA(A* p) { ptr = p; }
  ~PunteroA()    { delete ptr; }
};

int main()
{
  PunteroA a(new A);
  a->hola();          // error, "a" no es un puntero ni sobrecarga operator->
  return 0;
}

El anterior programa nos dará un error de compilación ya que el tipo PunteroA no soporta el operador flecha. Debemos agregarlo en la definición de la clase PunteroA:

class PunteroA {
  A* ptr;
public:
  PunteroA(A* p)  { ptr = p; }
  ~PunteroA()     { delete ptr; }
  A* operator->() { return ptr; }
};

int main()
{
  PunteroA a(new A);
  a->hola();        // ahora sí, PunteroA::operator->() nos devuelve
                    // el verdadero puntero A* y A::hola() finalmente
                    // es llamado
  return 0;
}

¿Cómo obtengo el A* desde un PunteroA? Debemos definir el operador de conversión hacia A*:

class PunteroA {
  A* ptr;
public:
  PunteroA(A* p)  { ptr = p; }
  ~PunteroA()     { delete ptr; }
  A* operator->() { return ptr; }
  operator A*()   { return ptr; }
};

Así podemos usar un PunteroA en funciones que reciban un A*. Ejemplo:

void func(A* a) { ... }

int main()
{
  PunteroA a(new A);
  func(a);
  return 0;
}

Generalizando: Podemos generalizar nuestro PunteroA para cualquier tipo de dato:

template<class T>
class ScopedPointer {
  T* ptr;
public:
  ScopedPointer(T* p) { ptr = p; }
  ~ScopedPointer()    { delete ptr; }
  
  operator T*()       { return ptr; }
  T* operator->()     { return ptr; }
};

Así podemos usar el mismo ScopedPointer para liberar instancias de cualquier clase:

int main()
{
  ScopedPointer<A> a(new A);
  ScopedPointer<B> b(new B);
  a->hola();
  return 0;
}

¿Y si quiero liberar otro tipo de recurso? Si el recurso no es memoria, y es liberado con otra función en vez de delete, podemos generalizar nuestro ScopedPointer con un nuevo parámetro de template llamado Destroyer:

struct DefaultDestroyer {
  template<class T>
  static void free(T* ptr) { delete ptr; }
};

template<class T, class Destroyer = DefaultDestroyer>
class ScopedPointer {
  T* ptr;
public:
  ScopedPointer(T* p) { ptr = p; }
  ~ScopedPointer()    { Destroyer::free(ptr); }
  
  operator T*()       { return ptr; }
  T* operator->()     { return ptr; }
};

En este caso, el destructor ~ScopedPointer llama a la función estática Destroyer::free. Esta función básicamente puede hacer lo que nosotros queramos. Podría ser útil para liberar ficheros o cualquier otro tipo de recurso:

struct FileDestroyer {
  static void free(FILE* ptr) { fclose(ptr); }
};

int main()
{
  ScopedPointer<FILE, FileDestroyer> file(fopen("hola.txt", "rt"));
  char buf[256];
  fread(buf, 1, 256, file);
}

¿No existen punteros de este tipo ya implementados? Boost tiene su propio scoped_ptr. También existen punteros más avanzados que cuentan referencias, como los smart pointers.

Interfaces vs. Conceptos

2009-10-18T12:21:00.005-03:00

¿Qué son los conceptos? Vamos a ver con un simple ejemplo, cómo podemos hacer una equivalencia entre las conocidas interfaces y los conceptos.

Imaginen esta "interfaz" (clase abstracta):

class IPortero {
public:
  virtual IPortero() { }
  virtual void ir_a_piso(int piso) = 0;
  virtual int piso_destino() = 0;
};

Tenemos otra clase Ascensor que podemos "personalizar" con nuestro propio portero, así nuestra implementación de portero puede hacer lo que se le de la gana:

class Ascensor {
  IPortero* m_portero;
public:
  Ascensor(IPortero* portero) {
    m_portero = portero;
  }
  void apretaron_boton_en_piso(int piso) {
    m_portero->ir_a_piso(piso);
    mover_ascensor(m_portero->piso_destino());
  }
  void mover_ascensor(int piso) { ... }
};

Con programación genérica, podemos reformular la interfaz convirtiéndola en un "concepto" y la clase Ascensor en una clase plantilla:

template<class TipoPortero>
class Ascensor {
  TipoPortero m_portero;
public:
  Ascensor() { }
  void apretaron_boton_en_piso(int piso) {
    m_portero.ir_a_piso(piso);
    mover_ascensor(m_portero.piso_destino());
  }
  void mover_ascensor(int piso) { ... }
};

La pregunta es, ¿qué demonios es TipoPortero?. La respuesta es sencilla: TipoPortero puede ser cualquier tipo de dato que cumpla los siguientes requisitos:

Tenga un constructor por omisión (que se pueda construir un nuevo TipoPortero sin argumentos, o sea, TipoPortero()).
Tenga una función miembro TipoPortero::ir_a_piso(int), la cual recibe un "int" (o cualquier tipo de dato que se pueda construir desde un "int" implícitamente).
Y otra función miembro TipoPortero::piso_destino() que devuelve un entero.

¿Cómo especificamos la "interfaz" o los "requerimientos" de un concepto? Sencillamente no se puede, C++0x iba a soportar esto, pero ya no. Hoy en día la mejor respuesta es usar algunos comentarios en la clase Ascensor que especifiquen qué espera en sus parámetros de template. En este aspecto se podría decir que IPortero es mejor porque especifica explícitamente lo que el portero tiene que hacer (funciones a implementar, etc.).

¿Qué ventaja tiene el concepto con respecto a las interfaces? La clase genérica Ascensor ahora tiene el mismo portero adentro suyo (no un puntero a la interfaz). Las llamadas a las funciones miembro ir_a_piso y piso_destino son llamadas directas (no tienen el overhead de una llamada a una función virtual).

Clases que "desaparecen" luego de compilar

2009-10-17T21:50:00.002-03:00

La magia de C++ es que, una vez compilado el código, algunas clases pueden desaparecer por completo (principalmente las que se usan en stack). O sea, aunque las clases abstraen al programador de los detalles de implementación, al final, el código termina siendo tan óptimo como si la clase no fuera utilizada en un principio.

Un ejemplo. Teniendo la siguiente clase Acumulador:

#include <cstdio>

class Acumulador {
  int v;
public:
  Acumulador()         { v = 0;                   }
  ~Acumulador()        { std::printf("%d\n", v);  }
  void acumular(int x) { v += x;                  }
};

Un código como el siguiente:

{
  Acumulador acum;
  acum.acumular(2);
  acum.acumular(4);
  acum.acumular(10);
}

Al compilarlo (optimizándolo), el código equivale a exactamente esto:

{
  int v = 0;
  v += 2;
  v += 4;
  v += 10;
  std::printf("%d\n", v);
}

La clase Acumulador ya no existe. Obtenemos el código más óptimo posible: sin llamadas a la función "acumular", ni ningún byte extra de memoria (Acumulador ocupa lo mismo de memoria que ocupa un "int").

Este ejemplo no ayuda a ver grandes ventajas, pero si el constructor y el destructor hacen tareas complicadas, y las funciones miembros también, el resultado puede llevarnos a dos puntos:

Nos abstrae de la complejidad de la implementación (e.j. para qué quiero saber cómo se acumula si sólo quiero acumular)
Obtenemos código tan óptimo como si no hubiéramos usado la abstracción (e.j. las operaciones se acercan al hardware tanto como sea posible).

C++0x no va a tener "conceptos"

2009-07-23T11:10:00.015-03:00

En la última reunión del ISO C++ Standards Committee decidieron quitar los "conceptos" del próximo estándar de C++ (que en realidad, en vez de C++0x va a ser C++1x y chirola). Un artículo de Bjarne Stroustrup habla al respecto:

[...] Básicamente, los "conceptos" tenían como meta hacer de la programación genérica algo más accesible a la mayoría de los programadores, pero esa meta ha sido para mí (Stroustrup) seriamente comprometida: En vez de hacer la programación genérica más accesible, los "conceptos" se fueron convirtiendo en otra herramienta más en las manos de los expertos (únicamente).
[...]
Para resumir y de alguna forma simplificar, he afirmado que:
Los "conceptos" como están actualmente definidos son muy difíciles de utilizar, lo que los llevará al desuso, dando la posibilidad a un desuso de los templates mismos y a la adopción completa de C++0x.
Un pequeño conjunto de simplificaciones [BS2009] pueden dejar a los "conceptos" lo suficientemente aceptables como para salir acorde a las fechas planificadas para C++0x o con sólo un retraso menor.
[...]

STL vector en vez de los clásicos buffers de C

2009-07-12T14:01:00.004-03:00

Algunas veces tenemos que crear buffers temporales. Por ejemplo, la función sprintf necesita de un buffer para poder dejar la cadena resultante. Ejemplo:

char buf[256];
sprintf(buf, "%d", 12345);
// usar "buf"...

Si queremos mantener el buffer en heap:

char* buf = malloc(256);
sprintf(buf, "%d", 12345);
// usar "buf"...
free(buf);

En C++ podríamos hacer uso de los operadores new[]/delete[]:

char* buf = new char[256];
sprintf(buf, "%d", 12345);
// usar "buf"...
delete[] buf;

Pero es aconsejable evitar la creación de arreglos con new[], y en su lugar hacer uso de std::vector:

std::vector<char> buf(256);
sprintf(&buf[0], "%d", 12345);
// usar "&buf[0]" en vez de "buf"...

El resultado: tenemos un buffer en el heap que se libera automáticamente (~std::vector) al salir del ámbito de la función que lo utiliza.

STL for_each

2009-03-21T08:44:00.003-03:00

Para recorrer un arreglo de C, podemos utilizar punteros. Comenzamos apuntando al primer elemento y frenamos una vez procesado el último elemento:

#include <stdio.h>

int main()
{
  int array[] = { 5, 3, 4, 9, 1 };
  int array_size = sizeof(array) / sizeof(int); // cantidad de elementos de "array"
  int *array_begin = array;                     // comienzo del array
  int *array_end = array+array_size;            // final del array (+un elemento)
  int *it;                                      // el iterator

  for (it = array_begin;  it != array_end;  ++it) {
    printf("%d\n", *it);
  }
  return 0;
}

Hay que tener en cuenta que array_end es igual a &array[5]. Sabiendo que sólo podemos acceder a los elementos desde array[0] a array[4], decimos que array[5] está más allá del último elemento del arreglo, es decir, &array[5] es la posición de memoria que ya no es parte del mismo arreglo (de ahí "it != array_end" significa "mientras nos encontremos dentro del arreglo").

¿Cómo recorrer un contenedor de la STL? La idea es similar, sólo que en vez de usar punteros utilizamos iteradores, y observe como la sintaxis del for es exactamente la misma. (nota: en este caso utilizamos un vector).

#include <iostream>
#include <vector>

using namespace std;

int main()
{
  vector<int> array;
  array.push_back(5);
  array.push_back(3);
  array.push_back(4);
  array.push_back(9);
  array.push_back(1);

  vector<int>::iterator it;

  for (it = array.begin();  it != array.end();  ++it) {
    cout << *it << endl;
  }
  return 0;
}

¿Cómo recorrer un contenedor STL con el algoritmo for_each? (nota: lo siguiente también se puede hacer con copy y ostream_iterator)

#include <cstdio>
#include <vector>
#include <algorithm>

using namespace std;

void print_element(int a) { cout << *it << endl; }
    
int main()
{
  vector<int> array;
  array.push_back(5);
  array.push_back(3);
  array.push_back(4);
  array.push_back(9);
  array.push_back(1);

  for_each(array.begin(), array.end(), print_element);
  return 0;
}

La función pasada como tercer parámetro a for_each es llamada por cada elemento del arreglo:

template
Function for_each(InputIterator first, InputIterator last, Function f)
{
  for (; first != last; ++first)
    f(*first);
  return f;
}

¿Por qué for_each devuelve la función? Principalmente porque la función "f" podría no ser una función! Podría ser un functor (objeto función), es decir, una instancia de una clase que tiene sobrecargado el operator() (llamada a función). Pero este tema se merece su propio post.

¿Se puede usar el algoritmo for_each para los arreglos de C? Sí.

#include <cstdio>
#include <algorithm>

using namespace std;

void print_element(int a) { printf("%d\n", a); }

int main()
{
  int array[] = { 5, 3, 4, 9, 1 };
  int array_size = sizeof(array) / sizeof(int); // cantidad de elementos de "array"
  int *array_begin = array;                     // comienzo del array
  int *array_end = array+array_size;            // final del array (un elemento más)

  for_each(array_begin, array_end, print_element);
  return 0;
}

STL generate

2008-12-08T14:18:00.009-02:00

Si usted tiene una función que genera números/valores/instancias (ej: un generador de números aleatorios, o identificadores) puede usar el algoritmo generate de la STL para crear una secuencia de objetos. Por ejemplo, para generar 100 números (pseudo)aleatorios de 0 a 1:

#include <algorithm>
#include <vector>

double uniform_random()
{
  return (rand() % 10001) / 10000.0;
}

int main()
{
  std::vector<double> v(100);
  std::generate(v.begin(), v.end(), uniform_random);
  return 0;
}

El algoritmo generate recibe dos iteradores (inicio y fin), y llama a la función especificada para cada una de las posiciones que recorre:

template<typename ForwardIterator, typename Generator>
void generate(ForwardIterator first, ForwardIterator last,
              Generator gen)
{
  for (; first != last; ++first)
    *first = gen();
}

Los algoritmos de la STL son genéricos porque utilizan la aritmética de punteros. Los iteradores sobrecargan los operadores para poder ser utilizados como punteros. Así un algoritmo puede ser utilizado con los contenedores de la STL (vector) o con los viejos y tan queridos arreglos (y punteros) de C:

#include <algorithm>

double uniform_random()
{
  return (rand() % 10001) / 10000.0;
}

int main()
{
  double v[100];
  std::generate(v, v+100, uniform_random);
  return 0;
}

¿Preincrementar o postincrementar?

2008-08-19T09:34:00.034-03:00

Hace mucho que quería escribir un post tan inútil como este. La duda que siempre me pasaba por la cabeza era la siguiente: ¿Será exactamente el mismo código ensamblador el que genera el compilador cuando utilizamos el preincremento o el postincremento (sin utilizar el valor de retorno)? Tenía la seguridad de que así debía ser (una optimización tan básica no podía ser dejada de lado), pero me faltaban las pruebas (en ensamblador) para verificarlo.

Recordando un poco, el preincremento

int a = 0;
int b = ++a;

hace a=1 y b=1, mientras que el postincremento

int a = 0;
int b = a++;

hace a=1 y b=0, esto significa que b obtuvo el valor de a anterior al incremento.

Aquí estamos utilizando el valor de retorno del operador incremento. El código ensamblador es distinto para cada caso. Vamos a echarle una mirada (antes le recomiendo ver este excelente artículo para comprender más sobre el stack y las convenciones de llamadas). En el preincremento el código ensamblador (generado por GCC 3.4.5 para i386) es:

subl  $8, %esp          // reservamos 8 bytes en el stack (para variables locales)
movl  $0, -4(%ebp)      // a   = 0
leal  -4(%ebp), %eax    // eax = &a
incl  (%eax)            // *eax= (*eax) + 1
movl  -4(%ebp), %eax    // eax = a
movl  %eax, -8(%ebp)    // b   = eax

En el postincremento

subl  $8, %esp          // reservamos 8 bytes en el stack
movl  $0, -4(%ebp)      // a   = 0
movl  -4(%ebp), %edx    // edx = a
leal  -4(%ebp), %eax    // eax = &a
incl  (%eax)            // *eax= (*eax) + 1
movl  %edx, -8(%ebp)    // b   = edx

donde se ve que el registro edx se utiliza para guardar el valor que tenía a antes del incremento para luego asignárselo a b.

Pero la pregunta original es, ¿qué pasa si no usamos el valor de retorno? ¿el código de ++i o i++ es igual? Debería serlo, y de hecho, lo es. Pero como veremos más abajo, esto sólo se cumple si utilizamos tipos de datos built-in (int, double, long, etc.). Miremos el siguiente código:

void func() { }
void pre () { for (int c=0; c<8; ++c) { func(); } }
void post() { for (int c=0; c<8; c++) { func(); } }
int main()
{
  pre();
  post();
  return 0;
}

Básico, un for pero con las dos variantes posible de incremento. El código generado para ambos casos (tanto para la función pre como post) es el siguiente:


  pushl %ebp              // guardar el viejo puntero a la base del stack
  movl  %esp, %ebp        // establecer la nueva base del stack
  subl  $4, %esp          // guardar 4 bytes en el stack (para variables locales)
  movl  $0, -4(%ebp)      // c = 0
L3:
  cmpl  $7, -4(%ebp)
  jg    L2                // si c > 7 entonces ir a L2
  call  _func             // llamar a la función func()
  leal  -4(%ebp), %eax    // eax = &c
  incl  (%eax)            // *eax= (*eax) + 1
  jmp   L3                // repetir yendo a L3
L2:
  leave                   // restaurar la base del stack (popl %ebp)
  ret                     // retornar al punto de llamada

Realmente es indiferente usar cualquiera de los dos tipos de incremento, salvo, en los tipos definidos por el usuario. C++ ofrece un soporte para tipos de usuario igual a los built-in (bueno, no del todo, pero lo están solucionando). Nos da la posibilidad de sobrecargar los operadores de nuestros propios tipos (clases). Por ejemplo:

class tipo {
  int x;
public:
  tipo(int y) : x(y) { }
  tipo(const tipo& y) : x(y.x) { }
  // preincremento
  tipo& operator++() {
    ++x;
    return *this;
  }
  // postincremento
  tipo operator++(int) {
    tipo tmp(*this);
    ++x;
    return tmp;
  }
  bool operator<(int y) const { return x < y; }
};

void func() { }
void pre()  { for (tipo c=0; c<8; ++c) { func(); } }
void post() { for (tipo c=0; c<8; c++) { func(); } }

int main()
{
  post();
  return 0;
}

No colocaré el código ensamblador por desbordar belleza, pero el código generado en este caso es distinto: cada incremento llama a la función correspondiente a su operador. Esto es debido a que ambas implementaciones varían considerablemente. Por ejemplo, el postincremento necesita de una instancia extra de tipo para poder devolver el anterior valor de this, en cambio, el preincremento devuelve una referencia al mismo this (sin necesidad de hacer una copia).

Como dato curioso, algo interesante ocurre al utilizar las optimizaciones del GCC. Si compilamos este último programa con el parámetro -O3, vamos a ver que todas las funciones correspondientes a la clase tipo desaparecen, y todo el código resultantes es inline, dando como resultado un código tan óptimo como si hubiéramos utilizado un int en vez de nuestra clase tipo.

¿Cómo obtengo el código ensamblador desde un archivo C/C++?
Con el compilador gcc, hay que utilizar el parámetro -S:

g++ -S -o archivo.s -c archivo.cpp

En archivo.s queda el código ensamblador (sintaxis AT&T).

Excepciones, RAII y auto_ptr

2008-06-24T15:28:00.040-03:00

Una de las mejores formas de realizar un control de errores es por medio de excepciones. Lamentablemente, si no se toman las precauciones adecuadas, se pueden obtener leaks de algunos recursos. Por ejemplo, imagine el siguiente caso:

int main()
{
  try {
    char *ptr = new char[256];
    double *matrix = new double[100000*100000]; // 74 Gigabytes
    // ...
    delete matrix;
    delete ptr;
  } catch (const std::bad_alloc& e) {
    std::cout << "No hay memoria suficiente" << std::endl;
  }
  return 0;
}

Aquí, con el segundo new una excepción bad_alloc es lanzada. El problema es que la memoria asignada con el primer new nadie la libera. Esto es un memory leak. Una opción para solucionarlo es mediante un bloque finally "a la Java":

int main()
{
  char *ptr = NULL;
  double *matrix = NULL;
  try {
    ptr = new char[256];
    matrix = new double[100000*100000];
    // ...
    delete matrix;
    delete ptr;
  } catch (...) { // finally
    if (matrix) delete matrix;
    if (ptr) delete ptr;
  }
  return 0;
}

Claro que esto no hace al manejo de errores una tarea transparente.

En C++ se puede utilizar la técnica RAII (la adquisición de recursos está en la inicialización), lo que ayuda a evitar leaks. La idea básica detrás de esto es que los constructores obtengan recursos, y los destructores los liberen. Al ocurrir una excepción, se van llamando los destructores de los objetos creados.

Para solucionar nuestro problema, podemos utilizar la clase auto_ptr que se encuentra en <memory>. Un auto_ptr guarda un puntero que es liberado automáticamente en el destructor.

int main()
{
  try {
    std::auto_ptr<char> ptr(new char[256]);
    std::auto_ptr<double> matrix(new double[100000*100000]);
    // ...
  } catch (const std::bad_alloc& e) {
    std::cout << "No hay memoria suficiente" << std::endl;
  }
  return 0;
}

Los deletes no son necesarios. Al salir del ámbito del bloque try, ya sea normalmente o por excepción, se llamará al destructor de los auto_ptrs creados, así no se incurre en ningún tipo de leak.

Advertencia: Los auto_ptr deben ser utilizados sabiendo cuál es su verdadero funcionamiento: La copia de un auto_ptr a otro no los deja equivalentes. La última copia se queda con el puntero, los demás lo van perdiendo, y el delete lo invoca el último auto_ptr destruido. Por ejemplo:

{
  std::auto_ptr<Persona> otra_persona;
  {
    std::auto_ptr<Persona> una_persona(new Persona);
    otra_persona = una_persona;
    // ahora "una_persona" apunta a NULL
  }
} // aquí la persona es destruida

Pregunta: ¿Por qué no usar objetos alojados en el stack en vez del heap para evitar los leaks? Porque el stack es mucho más pequeño. Por ejemplo, el siguiente código provoca un SIGSEGV ya que el arreglo no entra en el stack:

double matrix[1000000];

Pero sí entra en el heap:

double *matrix = new double[1000000]; // 7.6 Megabytes

Compilando archivos

2008-05-10T00:30:00.002-03:00

Suponiendo que conoce qué es un archivo de código fuente, código objeto, un ejecutable .exe, y el código máquina; voy a pasar a explicar algunos comandos del GCC para compilar.

Retomando la idea del anterior post, imagínese que creamos un archivo timemark.h para darle un poco de portabilidad a todo este asunto de medir el desempeño de una rutina. Las declaraciones de timemark.h pueden ser usadas para crear un pequeño programa ejemplo1.c que sea independiente de la plataforma (por lo menos entre Windows y GNU/Linux).

Vamos a probar algunas operaciones sobre la línea de comandos para ver cómo compilar este archivo. Inicialmente, la opción más sencilla es utilizar directamente "gcc ejemplo1.c", esto nos da como resultado el archivo "a.exe" o "a.out". Veamos (teniendo timemark.h y ejemplo1.c en un directorio C:\ejemplo1):

C:\ejemplo1>gcc ejemplo1.c
C:/Temp/ccMjdaaa.o:ejemplo1.c:(.text+0x31): undefined reference to `get_timemark'
C:/Temp/ccMjdaaa.o:ejemplo1.c:(.text+0x3c): undefined reference to `get_timemark'
C:/Temp/ccMjdaaa.o:ejemplo1.c:(.text+0x4e): undefined reference to `timemark_diff'
collect2: ld returned 1 exit status

Como podrá ver, recibimos un error por las funciones no definidas get_timermark y timemark_diff. Esto se debe a que utilizando solamente "gcc ejemplo1.c", se intenta enlazar el código de ese único archivo en el ejecutable. Tenemos algunas opciones intermedias antes de crear el .exe final. Por ejemplo, podemos crear un archivo que contenga el código objeto ya compilado (pero únicamente del archivo en cuestión ejemplo1.c):

C:\ejemplo1>gcc -o ejemplo1.o -c ejemplo1.c

Así obtenemos el ejemplo1.o (código objeto). En este caso no recibimos errores ya que ejemplo1.o hace referencias a las funciones get_timermark y timemark_diff, pero no necesita su implementación específica. Cuando creamos el ejecutable final (.exe) es cuando realmente necesitamos el código de todas las funciones invocadas.

El archivo que falta es timemark.c. Del mismo modo, podemos compilarlo con el comando:

C:\ejemplo1>gcc -o timemark.o -c timemark.c

Ahora resta unir ambos archivos objetos en un único ejecutable, con un único punto de acceso (main):

C:\ejemplo1>gcc -o ejemplo.exe ejemplo1.o timemark.o

Y listo. Por ahora, lo aprendido son estos dos comandos:

gcc -o archivo.o -c archivo.c
gcc -o archivo.exe archivo1.o archivo2.o archivo3.o ...

El primero compila el código fuente para generar un archivo objeto, y el segundo comando reune (enlaza, linkea) el grupo de archivos objetos en un ejecutable único.

De todas formas, es bastante tedioso escribir estos comandos cada vez que queremos compilar. Para resolver el problema podemos utilizar los llamados Makefiles. Claro, lo más interesante queda para un futuro post.

Medir el tiempo de una rutina

2008-03-01T11:59:00.010-02:00

¿Alguna vez se preocupó por la velocidad con la que corre su programa? ¿No? Entonces usted es un candidato perfecto para jugar al Java. En caso contrario, voy a explicarle un pequeño código que utilizaremos en próximas entregas para medir el tiempo de ejecución de determinadas rutinas.

Ya lo dijo alguien: "La optimización prematura es la raíz de todos los males". No hay nada más cierto, aunque también es verdad que hacer algo simple de la peor forma posible, es la causa de otros grandes males. Con esto quiero decir que debería intentar hacer las cosas de la forma más simple y más óptima que usted conozca (dándole mayor importancia a la simplicidad del código); luego se preocupa por "darle velocidad" a la rutina que provoca el cuello de botella (en próximos posts veremos cómo usar gprof para detectarlo).

La forma de calcular el tiempo de CPU que toma una función es muy simple:

tomamos el valor del reloj antes de realizar la llamada (t_ini),
llamamos a la rutina en cuestión, y
tomamos nuevamente el valor del reloj (t_fin).

La diferencia entre t_fin - t_ini nos da el total de tiempo que tomó: 1) hacer la llamada a la rutina, 2) que esta haga su trabajo, 3) que devuelva el resultado.

Ahora hay algunos pequeños detalles de implementación. Por ejemplo, ¿qué función usar para tomar el tiempo del reloj? Y más importante, ¿qué precisión obtenemos con dicha función?

Para tomar el tiempo podemos usar la rutina clock(), que devuelve el tiempo aproximado de CPU que transcurrió desde que nuestro programa fue iniciado, dicho tiempo representado en un valor de tipo clock_t: un valor entero que indica una cantidad de "tics" de reloj.

La precisión que tenemos con dicha rutina es de CLOCKS_PER_SEC (tics de reloj por segundo), lo que significa que por cada segundo que pasa, la función clock() nos devolverá CLOCKS_PER_SEC unidades más que el valor anterior. En MinGW, CLOCKS_PER_SEC es igual a 1000, pero es mejor no fiarse de esto, ya que en otras plataformas dicho valor varía. Inclusive, según POSIX, la constante CLOCKS_PER_SEC debería ser 1000000.

Veamos algo de código:

#include <stdio.h>
#include <time.h>

int main(int argc, char *argv[])
{
  clock_t t_ini, t_fin;
  double secs;

  t_ini = clock();
  /* ...hacer algo... */
  t_fin = clock();

  secs = (double)(t_fin - t_ini) / CLOCKS_PER_SEC;
  printf("%.16g milisegundos\n", secs * 1000.0);
  return 0;
}

Con esto podemos medir cuántos milisegundos demoró "hacer algo". Todo parece muy bonito hasta que nos damos cuenta de dos grandes problemas:

Tomar una medida única y aislada es igual que tomar un número completamente aleatorio y mostrarlo (no es una muestra representativa). Es mejor repetir las mediciones unas cuantas veces (y hablo del orden de las 100, o 100000, o 1e32 veces), y luego sacar un promedio de todo.
La función clock() no llega a tener una precisión ni de 10 milisegundos (aunque CLOCS_PER_SEC sea 1000 o más).

Una vez dicho esto, el código de arriba no sirve ni para limpiarse los trastes... Así que tenemos que buscar una función con mayor precisión, y además, promediar varias muestras.

Existen otras alternativas como la función gettimeofday, pero bajo Windows sufre del mismo problema de precisión que clock(). Igualmente en Linux funciona perfectamente, así que vale la pena tener en cuenta este código:

#include <stdio.h>
#include <time.h>
#include <sys/time.h>

/* retorna "a - b" en segundos */
double timeval_diff(struct timeval *a, struct timeval *b)
{
  return
    (double)(a->tv_sec + (double)a->tv_usec/1000000) -
    (double)(b->tv_sec + (double)b->tv_usec/1000000);
}

int main(int argc, char *argv[])
{
  struct timeval t_ini, t_fin;
  double secs;

  gettimeofday(&t_ini, NULL);
  /* ...hacer algo... */
  gettimeofday(&t_fin, NULL);

  secs = timeval_diff(&t_fin, &t_ini);
  printf("%.16g milliseconds\n", secs * 1000.0);
  return 0;
}

Como puede ver la estructura timeval contiene dos campos, segundos y microsegundos transcurridos (tv_sec y tv_usec respectivamente), por lo tanto ofrece una precisión de microsegundos. De todas formas, como decía esto en Windows no sirve y la razón es sencilla, en la misma MSDN explican que el temporizador del sistema corre aproximadamente a unos 10 milisegundos, por lo tanto, cualquier función que lo utilice nos estará dando la misma asquerosa precisión (inclusive al utilizar GetSystemTimeAsFileTime y FILETIME). Por lo tanto la solución es utilizar lo que se conoce en el mundo de Windows como el "contador de rendimiento de alta resolución" (high-resolution performance counter):

#include <stdio.h>
#include <windows.h>

/* retorna "a - b" en segundos */
double performancecounter_diff(LARGE_INTEGER *a, LARGE_INTEGER *b)
{
  LARGE_INTEGER freq;
  QueryPerformanceFrequency(&freq);
  return (double)(a->QuadPart - b->QuadPart) / (double)freq.QuadPart;
}

int main(int argc, char *argv[])
{
  LARGE_INTEGER t_ini, t_fin;
  double secs;

  QueryPerformanceCounter(&t_ini);
  /* ...hacer algo... */
  QueryPerformanceCounter(&t_fin);

  secs = performancecounter_diff(&t_fin, &t_ini);
  printf("%.16g milliseconds\n", secs * 1000.0);
  return 0;
}

En este caso, imagine que QueryPerformanceCounter es como clock() y QueryPerformanceFrequency es como CLOCKS_PER_SEC. Es decir, la primera función nos da el valor del contador, y la segunda su frecuencia (en ciclos por segundo, hertz). Cabe aclarar que un LARGE_INTEGER es una forma de representar un entero de 64 bits por medio de una unión (union).

Como tarea al lector, si es que existe alguno, le queda hacer una versión "portable" (entre Windows y Linux) para medir el rendimiento (con unos cuantos #ifdef WIN32 y #endif sería suficiente).

18 de Marzo del 2008: acá transcribo una macro que me pasó el amigo Carlos Becker para medir el tiempo de una rutina en Linux mediante clock_gettime:

#define TIME_THIS(X) \
  { \
    struct timespec ts1, ts2; \
    clock_gettime( CLOCK_REALTIME, &ts1 ); \
    X; \
    clock_gettime( CLOCK_REALTIME, &ts2 ); \
    printf( #X " demora: %f\n", \
      (float) ( 1.0*(1.0*ts2.tv_nsec - ts1.tv_nsec*1.0)*1e-9 \
      + 1.0*ts2.tv_sec - 1.0*ts1.tv_sec ) ); \
  }

/* podemos usarla así */
{
  double x, y, z;
  x = 2.0;
  y = 4.0;
  TIME_THIS(z = sqrt(x*x + y*y));
}

Lo que da como resultado:

z = sqrt(x*x + y*y) demora: 0.015164

Conseguir un compilador

2008-02-17T16:55:00.008-02:00

Editado 21 de mayo 2011: Este post se encuentra aquí sólo a fines históricos, ahora usted puede usar el instalador automático de MinGW.
Editado 9 de septiembre 2010: Aunque este post contiene información útil de cómo instalar MinGW con gcc 3.4, tal vez prefiera antes probar este nuevo post sobre cómo descargar MinGW con gcc 4.5 de forma automática.

En este blog vamos a hablar sobre los lenguajes de programación C y C++, y cómo usar software GNU para hacer aplicaciones. También voy a tratar de investigar algo de ensamblador.

De todas formas, para evitar hacer un primer post completamente inútil "de presentación", voy a pasar a explicarles cómo pueden instalar un compilador gratuito en Windows desde cero, y hacer un pequeño programa "Hola Mundo" sin pensar mucho (eso sí, van a tener que leer un poco). El proceso para Linux es más sencillo, ya que el compilador suele venir instalado por defecto en la mayoría de las distribuciones.

Primero, algunas definiciones importantes:

MinGW: Un conjunto de programas y bibliotecas que permiten crear aplicaciones para Windows.
GCC: El compilador. Transforma código escrito en C/C++ a un archivo ejecutable (.exe). En realidad hace miles de maravillas más, pero por ahora nos vamos a quedar con esta definición.
MSYS: Es un conjunto mínimo de programas para poder ejecutar scripts "a la" Unix. Además incluye una terminal que emula un pequeño entorno GNU/Linux.
Emacs: La madre de los editores de texto. Alguna vez dije que era una porquería o muy complicado, y que conviene usar editores como el RHIDE o Setedit. Bueno, la cosa es que con "un poco" de práctica uno comprende el poder de esta herramienta.
make: Un programa que puede compilar muchos archivos y linkearlos en un ejecutable de forma automatizada (siempre y cuando le escribamos un archivo con las órdenes adecuadas). Generalmente los programadores están acostumbrados a utilizar un IDE (como el DevC++) que maneje el proyecto, calcule las dependencias entre archivos, compile todo lo necesario, linkee, ejecute y depure. Si bien esto es cómodo, espero poder enseñarles a automatizar la compilación y liberarlos de un determinado IDE para compilar los programas.
cmd.exe: Es la línea de comandos de Windows. Si nunca lo utilizó, es hora que se ponga a usarlo. Para iniciar la línea de comandos debe ir al menú "Inicio/Ejecutar..." e introducir "cmd". ¿Cómo se usa? Bueno, empiece a buscar...

Ahora nos dedicaremos a instalar el MinGW, para eso debe comenzar a bajarse los siguientes archivos (si no sabe cómo descomprimir un archivo .tar.gz...):

mingw-runtime-3.13.tar.gz: Los archivos de cabecera y bibliotecas estándares (stdio.h, math.h, libc, libm, etc.)
w32api-3.10.tar.gz: Archivos de cabecera del API de Win32
gcc-core-3.4.5-20060117-1.tar.gz: El preprocesador de C y el compilador de C
gcc-g++-3.4.5-20060117-1.tar.gz: El compilador de C++ y los archivos de cabecera de C++
binutils-2.17.50-20060824-1.tar.gz: Varios programas utilitarios que sirve para diferentes propósitos (ej: quitar símbolos de depuración con strip, convertir direcciones a líneas de código fuente con addr2line, procesar la información de rendimiento con gprof, crear librerías con ar, compilar los archivos de recursos de Windows con windres, etc.).
mingw32-make-3.81-2.tar.gz: La utilidad make
gdb-5.2.1-1.exe: El depurador de código

Una vez que consiga todos estos archivos, debe crear una carpeta C:\MinGW (le recomiendo esa ubicación) y descomprimir todo ahí mismo. Para instalar el depurador (gdb) deberá ejecutar el instalador, seguir los pasos, y colocar como carpeta de instalación "C:\MinGW".

Una vez instalado todo, usted ya está en condiciones para compilar código en C o C++. Antes verifique que en dicha carpeta tiene una estructura de directorios como la siguiente:

C:\MinGW
  bin\
  doc\
  include\
  info\
  lib\
  libexec\
  man\
  mingw32\

Si así es, significa que todo salió bien (bueno, tampoco descomprimir unos archivos es algo tan complicado).

Para estar seguros que el compilador funcione, vamos a crear el programa de prueba por excelencia, el "Hola Mundo". Abra el bloc de notas (Inicio/Ejecutar/notepad) y escriba en un archivo el siguiente código:

#include <stdio.h>

int main(int argc, char *argv[])
{
  printf("Hola Mundo\n");
  return 0;
}

Guarde el archivo como "C:\MinGW\hola.c". Ahora abra la línea de comandos cmd.exe, y ahí mismo ejecute los siguientes comandos:

cd C:\MinGW
set PATH=C:\MinGW\bin;%PATH%
gcc hola.c

Verá que el archivo "a.exe" se crea en el directorio C:\MinGW. Si ejecuta el programa a.exe visualizará en la salida de la consola el mensaje más estúpido jamás escrito: "Hola Mundo"

C:\MinGW>a.exe
Hola Mundo

A continuación le paso a explicar qué hicimos en esta ráfaga de pasos:

"cd C:\MinGW" es para ubicarnos en el directorio donde se encuentra el archivo o proyecto que queremos compilar (si no sabía esto, es porque todavía no estuvo buscando cómo usar cmd.exe...).
"set PATH=C:\MinGW\bin;%PATH%" es un conjunto de varias cosas: "PATH" es una variable de entorno que indica cuáles son los directorios donde podemos encontrar archivos ejecutables (archivos ejecutables como gcc.exe, cpp.exe, etc.); "set" es un comando del shell para cambiar el valor de una variable de entorno; y "%PATH%" devuelve el valor de dicha variable de entorno. Por lo tanto, lo único que estamos haciendo aquí es agregar una nueva ruta (C:\MinGW\bin) a PATH para que el shell encuentre los archivos ejecutables que a nosotros nos interesa (el preprocesador, compilador, etc.). Si desea ver dónde busca el shell los archivos ejecutables actualmente, puede usar el siguiente comando: "echo %PATH%"
"gcc hola.c" compila el programa "hola.c" y deja el resultado (linkea o linkedita) en un archivo llamado "a.exe" (o "a.out" en Linux). En otros posts veremos cómo podemos especificar un nombre distinto a este archivo de salida.

De todo lo visto, lo más molesto es la configuración de la variable de entorno, es decir, si pensamos compilar varias veces, cada vez que abramos un shell (cmd.exe) deberemos hacer un "set PATH=C:\MinGW\bin;%PATH%". Para evitar este paso tenemos dos opciones:

Si tiene accesos de Administrador, puede hacer click derecho sobre "Mi PC", "Propiedades", "Opciones Avanzadas", "Variables de Entorno" y modificar la variable PATH agregándole el valor "C:\MinGW\bin" (recuerde no tocar las demás rutas, además de agregar un ";" para separar las distintas rutas entre sí).
En otro caso, puede crearse un archivo de comandos por lotes mi-mingw.bat para iniciar el shell adecuadamente con el PATH ya configurado. Por ejemplo, un mi-mingw.bat posible podría ser:
```
set PATH=C:\MinGW\bin;%PATH%
start cmd.exe
```
Este archivo podemos dejarlo en el Escritorio y cada vez que tengamos ganas de compilar, con un simple doble click ya podemos empezar. Inclusive, en vez de iniciar "start cmd.exe" podríamos iniciar algún IDE o editor de texto como Emacs. Pero eso para otro post.

Bueno, por hoy me cansé. Cualquier problema o pregunta que tengan, los comentarios están abiertos (y bien moderados :)