Acabo de venir de defender oFlute como Proyecto Fin de Carrera de la Ingeniería Técnica en Informática de Sistemas, con un resultado muy favorable. ¡He obtenido un 10-Sobresaliente de nota!

Muchas gracias a todos por el apoyo

Ahora bien, mi opinión es que se puede decir de las dos maneras, basándome en una razón puramente semántica más que de traducción directa. Cuando hablamos de una library, utilizamos esa palabra como metáfora del conjunto de clases, funciones, ficheros y demás que la conforman, igual que cuando le decimos a un ávido lector «¡qué biblioteca tan variada tienes!» nos estamos refiriendo al conjunto de libros, no a las estanterías. En definitiva, nos estamos acogiendo a la cuarta acepción de biblioteca en el dRAE.

Si nos vamos al artículo de librería en el mismo dRAE, vemos que su segunda acepción indica que es un sinónimo de la definición previamente mencionada de biblioteca. Por lógica, se concluye que a una colección más o menos numerosa de libros se le puede llamar tanto biblioteca como librería. Quedando clara la equivalencia de ambos términos para ese significado, que es el que se utiliza al traducir library del inglés, queda igualmente validada la posibilidad de usar ambos términos al traducir aquél.

Q.E.D.

Por twitter y a algunos por GTalk les he comentado mis últimas y cambiantes opiniones sobre Gosu. Para los no iniciados, Gosu es una biblioteca open-source y multiplataforma para el desarrollo de videojuegos 2D, con aceleración OpenGL y un esquema de clases sencillísimo de usar. Lo he usado activamente estos últimos dos años, tanto en mi proyecto oflute, como en freegemas y en otros proyectos personales, y además he escrito tres artículos para la edición española de la revista Linux Magazine que trataban sobre los conceptos básicos del desarrollo de videojuegos con Gosu. Por último, estoy preparando un taller sobre Gosu para las VI JOSLUCA. Creo que esto pondrá en perspectiva al lector en cuanto a mi familiaridad con Gosu.

Las razones por las que me está decepcionando son varias. El principal (y único, creo) desarrollador de Gosu es Julian Raschke, un tío con mucho talento que lleva bastantes años detrás del proyecto. Por desgracia, es 100% maquero, y claro, eso se nota en el progreso de Gosu: lógicamente, la plataforma para la que más pulido está es Mac OS y iOS, seguido de Windows (por la obvia superioridad en el mercado de videojuegos) y por último Linux, que es la plataforma menos pulida de todas.

Quede claro que me parece loable el trabajo de Julian en cuanto a llevar hacia adelante el desarrollo en plataformas tan diversas, sobre todo en un tema tan variopinto como es una biblioteca para gamedev. Pero sin duda, se nota que Linux no es la que más atención recibe. El script de autotools, por ejemplo, lleva años sin actualizarse y con muchos errores de compilación

Uno de los problemas con los que me encontré al empezar mi andadura con Gosu fue que, en Linux, no se podían cargar fuentes si no estaban instaladas en el sistema. Es decir, no podías adjuntar un .ttf con tu proyecto con una fuente para tu menú principal, sino que, una de dos, o hacías que el usuario instalara la fuente (que es un coñazo en sistemas GNU/Linux) o convertías los textos a imágenes en tu Photoshop (olvidándote de los textos dinámicos). Este problema llevaba así desde el principio y nadie se había parado a intentar arreglarlo. A mí se me ocurrió adaptar la biblioteca SDL TTF, y le ofrecí un parche a J. Raschke, que amablemente incluyó en la distribución oficial, siendo posible desde entonces usar fuentes TTF en Linux.

Pero claro, de aquí surgió otro problema: ahora las fuentes no aparecían exactamente igual en los diferentes sistemas. De hecho, en Windows y en Linux, para un mismo tamaño de fuente, el renderizado era diferente. Teóricamente, esto se arregló en una de las últimas versiones, pero yo no estoy del todo convencido.

Otro problema que encontré hace poco es un pequeño bug, también solo de Linux, en el el método para ocultar el puntero del ratón no tenía efecto alguno, mostrándose siempre. Propuse una solución en el foro y supongo que para la próxima versión se incluirá.

Pero la gota que casi ha colmado el vaso ha sido en el tema del sonido. En este aspecto, Linux también andaba atrasada respecto a las otras plataformas. En particular, era Linux el único SO en el que a los sonidos no se les podía modificar el tono. En un intento por arreglar esto y unificar el back-end de sonido de Windows y Linux, se portó el sistema a la biblioteca Audiere. Pero, ay amigos, fue peor el remedio que la enfermedad. Audiere solo funciona con OSS, y esto la limita a que solo pueda haber un programa accediendo al dispositivo de sonido a la vez, por lo que si, por ejemplo, tenemos un vídeo de youtube abierto, no podremos lanzar nuestro juego. He hablado con Raschke y la decisión más probable es que se volverá a SDL Mixer mientras se buscan otras soluciones, basadas principalmente en OpenAl.

A mí Gosu me encanta, me parece facilísimo de usar y probablemente siga usándolo a medida que vayan mejorando. Pero todas estas cosas, que siempre pasan en la plataforma donde más trabajo, que es Linux, hacen que me esté planteando buscar otra opción con una comunidad más fuerte y mayor estabilidad, además de que me joden mucho, porque he dado mucha caña con Gosu y siempre me ha parecido una opción muy buena.

Lógicamente no voy a dar un paso atrás y volver a la SDL, ni tampoco voy a desechar el trabajo hecho con Gosu, que aún funciona. Pero quiero abrirme otras puertas que sean más sólidas.

Estamos a 13 de septiembre, que casualmente es el día número 256 del año, lo cual lo convierte, por iniciativa popular, en el Programmer Day. Sentíos orgullosos.

Dejando de lado las festividades de dudosa relevancia, os pongo un poco al día del estado de oFlute:

• Tenía pensado (y aún guardo alguna esperanza) presentar el proyecto a finales de septiembre. Para ello tendría que entregar la memoria, como muy tarde, este viernes día 17, cosa harto improbable, ya que la escritura de documentos repletos de morralla no es mi fuerte, además de que la ingeniería del software es una de las materias peor impartidas en mi carrera, por lo que no estoy muy al día. Pero bueno.
• A pesar del punto anterior, voy a matricularme en el segundo ciclo de ingeniería informática, aquí en la Universidad de Cádiz. Se da la casualidad de que es posible matricularse sin tener la ingeniería técnica acabada, así que allá vamos. Entre el pseudo-gap-year que me he tomado, que el 99% del feedback que obtengo sobre el segundo ciclo es negativo y que todas las clases son por la tarde, no tengo muy claro cómo me va a ir este año. De todas formas tengo cierto proyecto secreto que tal vez me permita evadirme un poco.
• En cuanto al proyecto, las siguientes novedades respecto a la última vez:
  • La parte del software podría decirse que está terminada, aunque cada día lo miro y retoco algunas cosillas.
  • Deseché mi sistema de traducción bananero y le eché valor al tema, adaptando exitosamente el proyecto a gettext, que al fin y al cabo es muy sencillo de utilizar.
  • Adapté el algoritmo de drop-shadows de esta web y ahora puedo crear sombras al más puro estilo Photoshop de forma dinámica. Fijaos en el antes y después:

    

  • What else… Bueno, la parte de las canciones está terminada. Hago un llamamiento para que busquéis en vuestros cajones los cuadernos de pauta con canciones de flauta, que falta me hacen aunque probablemente acabe metiendo, de oído, canciones de videojuegos famosos
• Y algunas cosillas más que se me escapan.

¡Os mantendré informados!

Leyendo su entrada en Wikipedia y algunos comentarios en StackOverflow, vi que actualmente se desaconseja su uso, prefiriéndose las alternativas que la mayoría de compiladores ofrecen de forma nativa. Así fue como conocí la opción -MM de gcc, cuyo cometido es el mismo que el de makedepend: generar, en formato makefile, una lista de dependencias para cada fichero, basándose en las cabeceras incluidas. El funcionamiento es sencillo:

gcc -MM $(CXXFLAGS) ficherosFuente

Es importante pasarle las flags de compilación, ya que suelen incluir directivas como -I, que indican las carpetas en las que buscar ficheros de cabecera.

Problema 1: utilización de las dependencias generadas

La utilidad makedepend automáticamente actualizaba el makefile que la ejecutaba, añadiendo al final del fichero las dependencias generadas. Sin embargo, gcc -MM muestra su resultado en la salida estándar (o en un fichero que indiquemos), en lugar de añadirlo al Makefile actual, por lo que había que buscar una forma de incluir el resultado en nuestro Makefile. Con utilizar

-include dependencias.dep

Podremos incluir cualquier fichero en nuestro Makefile como parte del mismo.

Problema 2: rutas en el fichero generado

En mi caso, tengo tres carpetas que cuelgan de la raíz del proyecto: src, obj e include, en las que se guardan los cpp, los ficheros objeto y las cabeceras respectivamente. El problema de gcc -MM es que, al generar las dependencias, quita la ruta de la cabecera de las reglas, esto es, si tenemos un fichero objeto obj/main.o que depende de main.cpp, en el fichero generado aparecería así:

main.o: src/main.cpp

Por ahora, la única solución que he encontrado es utilizar sed para añadir al inicio la ruta correspondiente, aunque me habría gustado que gcc incluyera una opción al respecto.

gcc -MM $(CXXFLAGS) $(shell ls -t $(SRCDIR)/*.cpp) | sed 's/^\([a-zA-Z]\+.o:\)/$(OBJDIR)\/\1/g' > $(DEPFILE)

La explicación de la expresión regular es muy sencilla: Simplemente, cada vez que encuentre al inicio de la línea el nombre de un fichero objeto, que añada el nombre del directorio de los objetos (OBJDIR) y luego el nombre del fichero. Se utilizan grupos, primero agrupando el nombre con paréntesis y luego haciendo referencia al grupo con \1.

Por último, comentar que he puesto como dependencia del binario final al archivo de dependencias, y como dependencia del archivo de dependencias (valga la redundancia) todos los ficheros de código. El objetivo es que, si modifico algún fichero de código, puede que los includes cambien, así que hay que regenerar las dependencias. Tal vez acabe quitando esta dependencia cruzada, ya que estar regenerando las dependencias constantemente es un rollo. Otra opción que tal vez baraje es la de tener un archivo de dependencias por cada fichero objeto, así la regeneración no será tan pesada.

Opciones hay muchas.

• Si utilizas un bucle for, al borrar un elemento el tamaño y los índices de los elementos también, por lo que la variable de seguimiento (típicamente size_t i) ya no vale.
• Si utilizas iteradores, al eliminar un elemento aquellos quedan invalidados.

Estuve pensando un poco cómo hacerlo y se me ocurrieron algunas formas poco ortodoxas o que podrían llevar a error. Una de las formas que encontré por internet fue la siguiente, con iteradores y un for algo especial:

for (iterator it = v.begin(); 
     it != v.end(); 
    ) 
{ 
    if (condition) 
	it = v.erase(it); 
    else 
	++it; 
}

Si os fijáis, el for no tiene tercer parámetro, sino que somos nosotros los que movemos el iterador manualmente. Para evitar la invalidación, utilizamos el valor de retorno de erase.

Pero otra forma de hacerlo, más elegante a mi parecer, era utilizar el algoritmo remove_if y un predicado adecuado. En mi caso, el contenedor tenía objetos de una clase con un método que devolvía un booleano tal que, si es verdadero, el elemento debería borrarse. En un primer intento hice

remove_if(contenedor.begin(), contenedor.end(), boost::bind<bool>(&Clase::Comprobar, _1));

Pero los elementos no se borraban. «Qué raro», pensé. Resulta que el funcionamiento de remove_if no es el de borrar directamente los elementos, sino que reordena los elementos a borrar al final del contenedor y devuelve un iterador que apunta al primero de esos elementos a borrar. Así, junto al método erase del vector, tenemos:

contenedor.erase(remove_if(contenedor.begin(), contenedor.end(), boost::bind<bool>(&Clase::Comprobar, _1)), contenedor.end());

Esto se conoce como el Erase-remove idiom y tiene hasta su propio artículo en la Wikipedia. Muy curioso.

Al formar parte de TR1, podréis encontrarlas:

• En la cabecera boost/tuple/tuple.hpp, como boost::tuple.
• En la biblioteca estándar, en la cabecera tr1/tuple, como std::tr1::tuple.

Las tuplas se declaran de manera similar a los pares, indicando la cantidad y tipos de los datos contenidos como parámetros de plantilla. Podemos inicializar los datos pasándole los valores al constructor.

boost::tuple<int, string, string> miTupla (1, "Cisco", "Pepe");

Para los pares, se utilizaba first y second para acceder a los datos, pero al tener un número variable de elementos, con las tuplas hace falta alguna forma más genérica. Para ello se proporciona la función paramétrica get, que recibe como parámetro de plantilla el índice el elemento al que queremos acceder. Al devolver una referencia, nos servirá tanto de getter como de setter.

string cadena = miTupla.get<1>();
miTupla.get<0>() = 5;

Otra de las utilidades que vienen con las tuplas es tie, que nos permitirá darle valor a varias variables de una vez, incluso utilizando el valor de retorno de una función. Además, tie funciona tanto con tuplas como con los pares tradicionales.

pair<int, int> fun (){
    return make_pair(5, 3);
}

int main(int argc, char *argv[])
{
    int a, b;
    tr1::tie(a, b) = fun();
    printf("a:%i, b:%i\n", a, b);
}

Las tuplas traen muchas más funciones y utilidades, como por ejemplo para personalizar los operadores de flujos facilitando la entrada y salida, y muchas otras opciones que podéis observar en la documentación oficial.

Hace unos pocos días comencé el proyecto FreeGemas, una versión open source del clásico Bejeweled escrita, cómo no, en C++ y Gosu.

Entre la noche del 7 y la mañana del 8 de julio tenía la parte del principal del motor andando. Creo que ha sido un gran ejercicio de diseño y desarrollo rápido, y espero seguir desarrollándolo. Huelga decir que todas las imágenes y recursos son libres. Ahora estoy en la búsqueda de sonidos libres, ¿sugerencias?.

En la web del proyecto podréis encontrar las instrucciones de instalación, que son casualmente similares a las de oFlute

Espero que os guste.

ACTUALIZACIÓN: acaba de lanzarse Guadalinex V8 y FreeGemas ha sido incluido en la distribución como uno de las novedades. Para más información y donaciones (xD) al desarrollador, dirígete a mi web personal JoseTomasTocino.com.

Conceptos previos

Un objeto función es una instancia de una clase que tiene definido el operador (). Esto nos permite usar el objeto como si de una función se tratara:

struct Functor{
  void operator()(){
    cout << "Waking up in vegas" << endl;
  }
};

int main(){
  Functor F;
  F();
}

El verdadero potencial de estos objetos radica en que permiten expandir de manera sencilla la mayoría de los algoritmos de la STL de C++, ya que suelen poder recibir objetos función que modifiquen su funcionamiento para adaptarlo a nuestras necesidades.

Por ejemplo, el algoritmo for_each, contenido en la cabecera algorithm, nos permite iterar sobre un contenedor y aplicar una función por cada elemento (for each element). En estos casos, es útil utilizar un objeto función como extensión al algoritmo:

#include <iostream>
#include <boost/array.hpp>
#include <algorithm>

using namespace std;

struct Botella{
    string etiqueta;
    Botella(string e) : etiqueta(e) { }
};

struct Impresor{
    string destino;
    int n;
    Impresor(string d = "ERROR") : destino(d), n(0){ }

    void operator() (Botella & B){
	cout << destino << "(" << n++ << "): " << B.etiqueta << endl;
    }
};

int main(int argc, char *argv[])
{
    boost::array<Botella, 3> vector = { {Botella("Cruzcampo"),
					 Botella("San Miguel"),
					 Botella("Mahou") } };
    Impresor I("DEBUG");
    for_each(vector.begin(), vector.end(), I);
    return 0;
}

En la STL hay un gran número de algoritmos que podemos usar. Para más información, recomiendo la lectura del punto 8, capítulo 7, del libre «Fundamentos de C++», del Servicio de Publicaciones de la UCA.

La pega que tiene el uso de los objetos función en los algoritmos de la STL es que la sobrecarga del operador() debe tener un solo parámetro del tipo del contenedor, lo cual nos limita bastante.

Boost.Bind

Bind nos da la posibilidad de ligar los parámetros de una función o un objeto función a un valor concreto, o a otra posición. ¿Qué quiere decir esto? Si tenemos, por ejemplo, un objeto función que recibe dos parámetros y nos interesa que uno de ellos sea siempre el mismo, podemos usar bind. Notar que bind siempre devuelve un objeto función cuyo operador () estará ligado a la función original.

#include <iostream>
#include <algorithm>

#include <boost/array.hpp>
#include <boost/bind.hpp>

using namespace std;

struct Elemento{
    int n;
    Elemento(int n = 0) : n(n) { }
};

struct Comparador{
    void operator() (int n, Elemento & E){
	if(E.n > n)
	    cout << "HOYGAN, parece que este elemento (" << E.n 
		 << ") es mayor que " << n << endl;
    }
};

int main(int argc, char *argv[])
{
    boost::array<Elemento, 3> arr = {{Elemento(2),
				      Elemento(4),
				      Elemento(8)}};

    for_each(arr.begin(), arr.end(),
	     boost::bind<void>(Comparador(), 3, _1));
    return 0;
}

Si os fijáis, la sintaxis de bind es sencilla: Recibe un parámetro de plantilla que indica el tipo de dato de vuelto por la función ligada. Normalmente es capaz de deducir qué tipo de datos se devuelve, pero hay casos en los que es necesario indicarlo explícitamente.

Luego, recibe como argumentos la función u objeto función a ligar, y seguidamente los parámetros de ésta. Podemos indicar directamente el valor, o utilizar placeholders, que nos permiten ligar los parámetros de entrada con los de salida. En nuestro ejemplo, _1 que está en el segundo lugar indica que el segundo parámetro de la función será el primero que reciba bind.

La reorganización de parámetros se puede ver mejor con este otro ejemplo:

#include <iostream>
#include <algorithm>

#include <boost/bind.hpp>

using namespace std;

void fun (int A, int B){
    cout << "A: " << A << endl
	 << "B: " << B << endl;
}

int main(int argc, char *argv[])
{
    boost::bind(fun, _2, _1) (1, 2);
    return 0;
}

Boost.Function

En ocasiones nos interesará tener la función ligada como un objeto con el que trabajar, por ejemplo para poder recibirla como argumento de una función. Para esos casos, boost nos proporciona function. Se trata de una clase paramétrica cuyo operador () se sobrecargará para llamar a la función ligada.

class miClase{
public:

    void hacerSuma(int a){
        cout << "Hago una suma: " << a << endl;
    }

    void hacerResta(int a){
        cout << "Hago una resta: " << a << endl;
    }
};

int main(){
 boost::function<void(miClase, int)> operacion;

    if(1 == 0){
        operacion = boost::bind(&miClase::hacerSuma, _1, _2);
    }else{
        operacion = boost::bind(&miClase::hacerResta, _1, _2);
    }
    miClase c;
    operacion(c, 2);
}

Descargando, compilando y usando Boost

Además de su utilidad, las bibliotecas Boost brillan en su facilidad de uso, ya que la inmensa mayoría de las mismas están totalmente definidas en ficheros de cabecera que simplemente incluiremos en nuestro proyecto, evitando tener que compilarlas y enlazarlas de forma independiente. Hay una serie de bibliotecas que, por su complejidad, necesitan ser compiladas y enlazadas, pero son casos en los que la compilación es indispensable y merece la pena por la funcionalidad que ofrecen.

Hoy en día la mayoría de las distribuciones de GNU/Linux alojan en sus repositorios paquetes con las bibliotecas Boost. Por regla general, se distribuye un paquete con la mayoría de las bibliotecas de cabecera, y por separado un paquete por cada biblioteca que necesita enlazado. En esta serie de artículos se indicará convenientemente cuándo es necesario realizar alguna clase de operación especial al compilar y enlazar.

C++ Technical Report 1

Como comenté en el post anterior, vamos a empezar comentando por encima las bibliotecas de Boost que aparecen en el C++ Technical Report 1. Pero primero, ¿qué es ese documento?

Tal y como explica la wikipedia, se trata de un documento que propone una serie de adiciones a la biblioteca estándar de C++. No es un estándar en sí mismo, sino una propuesta borrador, aunque con toda probabilidad gran parte o la totalidad del mismo formará parte de la siguiente versión de C++. Por lo tanto, es interesante echarle un vistazo para familiarizarse con lo que está por llegar.

En cuanto a Boost, 12 de sus bibliotecas han sido incluídas en el TR1, aquí las veremos todas por encima y algunas con más profundidad.

Boost.Array

Documentación: http://www.boost.org/doc/libs/1_43_0/doc/html/array.html
Cabecera: boost/array.hpp

Se trata de un wrapper que adapta las arrays de tamaño fijo, típicas de C, para su uso como contenedor estándar, añadiendo una serie de métodos y tipos de datos tales como size y at, iteradores, etcétera. Las ventajas sobre los arrays clásicos son claras: métodos útiles para conocer el tamaño, métodos de acceso con control de límites, etcétera.

Hay muchas ocasiones en las que utilizamos std::vector incluso sabiendo que el tamaño no va a variar, simplemente por evitar utilizar arrays a pelo. En esos casos, boost::array es ideal, ya que comparte la mayoría de métodos de vector y, al no tener que lidiar con ampliaciones y reducciones dinámicas de memoria, es mucho más eficiente.

Por último, otra de las grandes ventajas de esta biblioteca es la posibilidad de inicializarse en línea como un agregado, lo que nos evita andar inicializando los elementos uno a uno.

#include <boost/array.hpp>

#include <iostream>
#include <string>

using namespace std;

int main(int argc, char *argv[])
{
    /*
      Ejemplo 1: Inicialización básica de un boost::array
    */
    boost::array<string, 3> primos = { {"Shurmano", "Shurprimo", "Shurperro"} };
    cout << primos[0] << endl
	 << primos[1] << endl
	 << primos[2] << endl;

    /*
      Ejemplo 2: Métodos típicos de los contenedores
     */

    // Tamaño
    cout << "Tamaño: " << primos.size() << endl;

    // Bound checking (comprobación de límites)
    try{
	cout << primos.at(4) << endl;
    }catch(std::out_of_range&){
	cout << "Fuera de rango" << endl;
    }

    // Iteradores
    cout << *primos.begin() << endl
	 << *(primos.end()-1) << endl;

    // Operadores
    boost::array<int, 4> yo = { {0, 1, 2, 3} };
    boost::array<int, 4> another = { {0, 1, 2, 5} };
    cout << ((yo == another)?"Iguales":"Diferentes") << endl;

    return 0;
}

En este enlace se explican las motivaciones y detalles detrás de boost.array.

Boost.Hash

Documentación.
Cabecera: boost/functional/hash.hpp

Un hash es una forma de identificar de forma unívoca a cualquier elemento. Se utiliza una función hash que, a partir de las propiedades de un objeto, genera un código único. Los hashes se suelen utilizar en contextos en los que es necesario identificar e indexar elementos, como en los contenedores. La ventaja que ofrece el indexar por hash en lugar de por otro tipo de clave es que la comparación de hashes es muy eficiente, por lo que los accesos se hacen más rápido.

Boost.Hash nos permite generar hashes para enteros, flotantes, punteros y cadenas de forma nativa, y además, provee soporte para la generación de hashes de tipos de datos definidos por el usuario y hashes combinados. La utilización de esta biblioteca es muy sencilla: simplemente creamos una instancia de la clase paramétrica boost::hash, que recibe como parámetro el tipo de dato a hashear. Seguidamente, cuando queramos generar un hash, utilizaremos el operador () del objeto creado.

boost::hash<std::string> string_hash;
    cout << "Hash de cadena: " 
	 << string_hash("Don't hash me, bro!") << endl;

Si tenemos un tipo de datos propio, por ejemplo una clase, y queremos calcular su hash, previamente tendremos que sobrecargar la función size_t hash_value(const T & t), siendo T nuestro tipo de datos. Dentro de esa función tendremos que implementar el algoritmo de hash para nuestra clase concreta.

Por regla general, a la hora de implementar el hash de un tipo propio, tenemos que fijarnos en qué propiedades tiene cada instancia de esa clase que la hace única. Si, por ejemplo, tenemos una clase código de barras con un atributo número que la identifica, el hash de la clase será el hash del código.

class codigoBarras{
  int numero;
public:
  // ...
  friend std::size_t hash_value(const codigoBarras & C){
    boost::hash<int> hasher; 
    return hasher(C.numero);
  }
};

Otro ejemplo: si tenemos una clase alumno con dos atributos nombre y apellido, el hash de esa clase será una combinación del hash del nombre y el hash del apellido.

class alumno{
  string nombre, apellido;

public:
  // ...
  friend std::size_t hash_value(const alumno & a){
    std::size_t valor = 0;
    boost::hash_combine(valor, a.nombre);
    boost::hash_combine(valor, b.nombre);
    return valor;
  }
};

Boost.hash se utiliza en la biblioteca Boost.unordered, que proporciona alternativas no ordenadas a los conjuntos (set) y mapas (map) de la STL, mejorando la eficacia en órdenes de magnitud.

Hasta aquí la primera entrega de estos artículos.