Boost filesystem

Una de las librerias que siempre vienen bien conocer en boost es la filesystem. Parece una tonteria pero se pueden llegar a gastar unas cuantas horas programando y debuggando un sistema de ficheros. Si ademas es multiplataforma todavía más. Por que a los separadores de ficheros, que segun el sistema puede ser "/" o "\", se suma que en sistemas windows existen las "unidades" (C: E: D:),  que en linux existen los enlaces soft y hard...

Además de estas dificultades, que plagan nuestro código de #ifdef win32 #elseif.... , otros problemas que muchas veces nos hace acabar recurriendo al socorrido system(cmd). Con boost tenemos un codigo unificado que no desordea nuestro codigo y que nos permite interactuar con el sistema de ficheros. Podemos añadirlo con la cabecera:

#include "boost/filesystem.hpp"

Lo primero que tenemos que conocer es la clase path. La declaramos asi:

boost::filesystem::path ruta("myDir");

Otra cosa importante es que el operator/ esta sobrecargado y hace la concatenacion de directorios. Junto con la ruta declarada antes, podriamos hacer:

boost::filesystem::path ruta("myDir");
boost::filesystem::path root("myRootDir");
boost::filesystem::path completeRoot = root / ruta;
// podriamos hacer lo mismo pero ahorrando una variable con root /= ruta

Dentro de la libreria podemos encontrar algunas funciones muy útiles para borrar y crear directorios y archivos:

boost::filesystem::create_directory("dir");
boost::filesystem::remove_all("file");

E incluso para saber si existe un archivo, conocer si es un directorio, un archivo o un link

boost::filesystem::exists("file");
if(boost::filesystem::is_directory("file"))
{}

Para acabar, los iteradores nos permiten recorrer los contenidos de un determinado directorio:

boost::filesystem::directory_iterator end_iter;
boost::filesystem::directory_iterator dir_iter(directory);
for(dir_iter; dir_iter != end_iter; ++dir_iter)
{

}

En zeleste2D, esta es la funcion para crear recursivamente una ruta que no existe:

//TODO: Would this method be more general and live outside this class??
bool pathCreator( boost::filesystem::path& path_to_create )
{
 if (!fs::exists(path_to_create))
 {
     pathCreator(path_to_create.parent_path());
 }
//if not create the directory
fs::create_directory(path_to_create);
return true;

Funciones, code forwarding y slicing

Está claro que cuando declaramos una función estamos estableciendo como nos comunicaremos con el código cliente. Pero todos conocemos que en c++ existen 3 maneras diferentes de pasar parámetros: por valor, por parámetros y por referencia. Como deberíamos diseñar pues la interface de nuestras funciones? Segun la guia de estilo de google deberíamos diseñar las funciones poniendo las variables de entrada y salida como punteros y las variables de entrada como referencias constantes. Algo asi:

type1& funct(const type2& ref, type3* point){}

Salvando memoria
La primera ventaja de las referencias en las funciones y métodos va por triplicado. Por un lado es transparente para el usuario, puesto que podemos insertar las variables sin semántica de punteros y manejarlas dentro de la función de la misma forma. Además, consumimos menos memoria, puesto que solo copiamos la referencia del parametro y no copiamos el objeto. Para darnos cuenta de cuando copiamos un objeto, una manera muy buenas es usar una macro como esta:

// A macro to disallow the copy constructor and operator= functions
// This should be used in the private: declarations for a class
#define DISALLOW_COPY_AND_ASSIGN(TypeName) \
  TypeName(const TypeName&);               \
  void operator=(const TypeName&)

Después podemos declarar nuestras clases asi:

class Foo {
 public:
  Foo(int f);
  ~Foo();

 private:
  DISALLOW_COPY_AND_ASSIGN(Foo);
};

Gracias a esto, nos aseguramos que el compilador nos prohiba copiar un objeto y pare la compilación. Es una buena costumbre la de usar el compilador para protegernos de errores.

Code forwarding
La segunda ventaja viene al diseñar clases , con el code forwarding. Cuando la interface de una clase solo declara punteros a otra clase, no necesitamos la cabecera para definirlos. Esto es: si tenemos una clase asi

class Forwarded;

class Declared{

    Forwarded* m_for;

    void fund(Forwarded* f);

};

Esta clase compilaria perfectamente, puesto que Forwarded son punteros asi que el compilador no necesita conocer ningun detalle más de Forwarded para compilar. Lo unico que necesitamos es declarar la clase de manera adelantada. Es una manera de decirle al compilador: "existe una clase llamada Forwarded. Tu compila, que luego de doy mas detalles". Pero cuando le damos los detalles? Pues en el fichero de codigo, en el .cpp, es donde se hace el include.

Y que ganamos con esto? La mayoria del tiempo que tarda la compilación es en operaciones recursivas de inclusion de codigo, o sea, en parseo. Cada vez que variamos una parte del codigo de un fichero afecta a todas las cabeceras incluidas de manera recursiva en esa unidad de compilacion. Declarando el include en el fichero .cpp retiramos esta cabecera del circuito y hacemos que la compilación sea mucho mas rápida

Slicing (rebanamiento)
La tercera ventaja es que evitamos el slicing. El slicing es un problema de c++ al copiar en una variable de tipo A, una variable de tipo B que deriva A. Si tenemos las clases

class A{

public:

    int t1;

};

class B: public A{

public:

    int t2;

};

Si hacemos esto:

B b;

b.t1 = 2;

b.t2 = 3;

A a = b;

// t2 no ha sido copiado.

B b2 = a;

assert(b2.t2 == b.t2); // esto fallará

Que ha pasado? Pues que en la copia entre clases, A no tiene un miembro t2, asi que no lo copia. Cuando volvemos a copiar A en B, ese miembro ya no esta en A y por tanto es indefinido en B. Este caso es claro en el codigo anterior pero se puede hacer más dificil de ver en el paso de parametros en una funcion que acepte parametros polimorficos. Al pasar la referencia, ayudamos a prevenir esta perdida de información. Por ejemplo

B* b = new B;

b->t1 = 2;

b->t2 = 3;

A* a = b;

B* b2 = a;

assert(b2->t2 == b->t2); //OK

Boost Hash

Esta entrada va a ser muy corta, o eso espero... Boost::hash es una libreria que nos facilita el calculo del hash de cualquier entrada. Más que facilitarlo lo soluciona completamente :)

Este seria un caso muy directo:

#include "iostream"
#include "boost/functional/hash.hpp"
int main()
{
    boost::hash string_hash;
    size_t myHash = string_hash("Hola mundo");
    std::cout << "Mi hash es " << myHash << std::endl;
    return EXIT_SUCCESS;   
}

Tambien se puede lo deberiamos usar para indexar maps. Imagina que tenemos una funcion que recibe un directorio y un objeto de una clase T, y que eso lo guardamos en un std::map. Los directorios son del tipo "c:\archivos de programas\bla bla bla\jejeje\archivo". Si te fijas, cuando se empieza a comparar la función,  los 15 primeros carácteres son siempre iguales, asi que podemos perder ciclos comparando. Lo que podemos hacer es, al insertar el objeto T, calcular el hash del directorio y devolver el hash como ID. Asi nuestros accesos posteriores seran rapidisimos.

std::size_t insert( const std::string& dir, T& objeto)
{
    std::size_t hash = string_hash(dir);
    myMap[hash] = objeto;
    return hash;
}

Ahora podriamos recuperar el objeto facilmente con el ID (no controlamos los errores).

T& get(const std::size_t id)
{
   return myMap[id];
}

Nota: He incluido las cabeceras como #include "iostream" por un tema del plugin de blogger, que me formatea mal el código, pero lo puedes poner como quieras.

Boost. Ponle el turbo a C++

Encuentro que hay mucha gente que desconoce Boost Supongo que también hay mucha gente que desconoce que C++ esta a punto de cambiar de standard, y que muchas de las funcionalidades nuevas están en Boost. De ahi que muchas de las sentencias como:

boost::Thread t1;

Pasarán a ser:

std::Thread t1;

Es decir, parte del estandar. Boost ademas ahonda en la idea de algunas tecnologias que implementa el nuevo estandar, como auto_ptr que boost completa con los scoped_ptr, shared_ptr, etc.
Por otro lado, boost llena agujeros que tradicioanlmente ha tenido C/C++. Por ejemplo, C++ no tiene una libreria unificada para tranajar con el sistema de ficheros. No hay una función que nos devuelva, por ejemplo, si un fichero existe y cuanto mide, y tenemos que recurrir a librerias de terceros. Tampoco tiene una libreria de fechas unificada.
Y eso que significa? Pues que cualquier programador de c++ deberia tener instaladas las librerias boost en su ordenador, y aprender a usarlas para no tener que reinventar la rueda constantemente.

Boost para novatos:
Pues de novato a novato te voy a decir una cosa. Boost no es dificil de instalar. De hecho es muy fácil:
Las bajamos desde esta pagina. En la sección de packaged downloads nos bajamos la última versión. Lo mejor es bajar el que esta comprimido en 7z por que es el mas pequeño en windows. En linux sirve el que quieras que sea gz. Ahora lo podemos instalar. En Window necesitamos 4 sencillos pasos:

1. Crear un destino
Creamos una carpeta en nuestro ordenador donde queramos instalar las librerias de manera definitiva. Por ejemplo en c:\dev-libs\boost. (lo mejor es que la ruta no tenga espacios en blanco, por si acaso)

2. Ir al constructor de boost

Al acabar de descomprimir tendremos una carpeta de nombre boost_version (puede ser boost_1_47_0 por ejemplo). Vamos dentro de esta carperta a .\tools\build\v2. Abrimos una consola y escribimos los siguientes comandos estando en esa ruta:

bootstrap.bat
.\b2

Esperamos a que acabe todo y entonces tendremos una herramienta llamada bjam. Ahora vamos a la raiz de boost (c:\dev-libs\boost en nuestro caso) y escribimos .\tools\build\v2\bjam y entonces empieza la construccion de boost de verdad.


3. Esperar
Ir a por un café. Si estas en el curro ves a hablar con esa de marketing tan guapa... esa que tu y yo sabemos. La compilación se puede alargar un ratito dependiendo de la máquina que tengas.


4. Añadir la ruta al PATH
Ahora solo te queda añadir lo que iba en prefix + bin, en mi caso c:\dev-libs\boost\1.47\bin al path. Aunque tambien podemos instalarlo directamente en Visual Studio para no enredar con el PATH. Para ello vamos a Herramientas -> Opciones -> Proyectos y soluciones -> Directorios de VC++. 

Alli añadimos "c:\dev-libs\boost\1.47\" en "Archivos de inclusion" y "c:\dev-libs\boost\1.47\stage\lib" en "Archivos de biblioteca". Asi boost estará disponible para cualquier proyecto.

Y con eso quedaria instalado. Ahora, sin ninguna confuguracion adicional del proyecto deberiamos poder compilar algo como esto:

#include 
#include 
#include 

int main()
{
    std::string line;
    boost::regex pat( "^Subject: (Re: |Aw: )*(.*)" );

    while (std::cin)
    {
        std::getline(std::cin, line);
        boost::smatch matches;
        if (boost::regex_match(line, matches, pat))
            std::cout << matches[2] << std::endl;
    }
}

Y con eso ya tendriamos boost instalado. En general ni es tan largo ni complicado como mucha gente piensa. Espero que esto te anime a empezar. En los proximos dias escribire algunas entradas sobre librerias de boost que me parecen especialmente utiles.

Pasitos con Unity

Hace unos días me baje Unity3D para trastear un poco y la verdad es que parece un producto muy bien hecho. Lo primero que sorprende es su sencillez de ideas. Tenemos la ventana de diseño, donde vemos la escena que hemos montado, la jerarquia, que es donde montamos la escena a base de interrelacionar assets, el panel de proyecto, que es donde nuestros assets disponibles estan listos para usarse y el panel de inspeccion.

Casi todo pasa con sencillez. Queremos una luz? Buscamos en el panel de proyecto por los tipos de luces disponibles, elegimos una, la arrastramos al panel de jerarquia y en el inspector podemos cambiarle las propiedades. Casi todos los elementos estan pensados asi, con lo que ganamos en sencillez.

Unitiy no sorprende por herrmamientas 3D, o de retoque de imagen o de sonido, sino que se limitan a aconsejarte que busques alguna herramienta de verdad como Maya o Photoshop. Pero Unity3D provee metodos para recoger los productos de estas herramientas y cargarlos como assets. Tambien viene con el editor mono, para javascript o c#. Y de momento eso es lo que he visto hasta ahora. Ya ire poniendo mas entradas donde explique como me va con Unity3D

Probando tu codigo en C++ con gtest (II)

El porque de las pruebas unitarias

En la entrada anterior planteaba la necesidad de hacer test unitarios, ademas de explicar como montar la librería  compilarla y usarla. Pero quizás hay una pregunta que no respondo y es: para que? Para que una librería cuando podemos hacer programas de ejemplo?
En esta segunda entrada quiero hablar desde un punto de vista diferente y explicar que se busca con las pruebas unitarias y que estrategia tomar para sacarle partido a estas:

Imagina que estas programando y usas las STL. Al ejecutar, aparece un error muy raro. Al debugar, la excepción salta en medio del código de una de las clases que implementan std::vector. Le echaras la culpa a las STL? Las mirarás en profundidad? No. Seguro que no. Tendrás la seguridad de que lo que falla es tu código, por que sabes que las STL han sido probadas una y otra vez (y aun y así todavía tienen errores, aunque son difíciles de encontrar). Esa tranquilidad agiliza el desarrollo puesto que en caso de error siempre miramos el último código. Esa es una de las fortalezas de la reutilización de código.

Cuando pruebas su código, muchas veces haces algunas funciones de prueba pero, lo haces de una manera estructurada? Por ejemplo, esta función:

int dividir(const int a, const int b)
{
   return (a/b);
}

Como la probarías?
En principio no haríamos nada raro: un par de llamadas y ver el resultado. Con google test seria así

TEST(funcionDividirTest, dividir)
{
    EXPECT_EQ(dividir(5,2),7);
    EXPECT_EQ(dividir(5,-5),0);
}

No hay nada que hacer. Al final siempre hay bugs. En este caso, por ejemplo, no se contempla la division por cero. Si has hecho bien tu trabajo de pruebas, arreglarás el bug, y añadiras una prueba más a tu set de pruebas, y te asegurarás de que en cada compilación se ejecuten todas las pruebas. La ganancia principal aquí con las pruebas unitarias es que podemos probar nuestro código cada vez que compilamos una nueva version. En codigo más complejo, cuando probamos funciones de más alto nivel, nos permitirá descubrir cuando alguien ha metido la pata.

La vista puesta en la calidad

Resolver bugs es aburrido y una perdida de tiempo. Lo mejor es no fallar al programar. Como es casi imposible, las pruebas unitarias hacen que una vez escritas las pruebas por alli ya no fallará el programa (y si falla sera algo muy localizado). No harías ningun sacrificio por esa buena causa? Pues intenta que el código sea probable. Para hacerlo, intenta que tus funciones y métodos devuelvan algo. Si la función no debería devolver nada, pues que devuelva 0 en caso de éxito y algún valor de error en caso contrario (debidamente documentado). Evidentemente, cambiar el diseño para que sea fácilmente probable puede ser costoso pero creo que se sale ganando con creces.

Se consistente en el manejo de errores. Devuelve un código de error o haz saltar una excepción, pero no mezcles estrategias en el código.

Lleva un control de lo que has probado, pero también de lo que no has probado. Es casi más importante saber que código esta en el aire.

Desacopla tu código, por que si no las inicializaciones son pesadas y penosas. Cada subsistema debería poderse compilar por separado (siempre que sea posible). Desacoplar el código significa que cada subsistema habla con los otros subsistema a través de unas interfaces muy determinadas. Hay que evitar situaciones donde cada clases de un subsistema tiene que conocer muchas cosas de otro subsistema

Test driven development

Pero se puede hacer algo más?
Pués si. Imagina que un jefe de proyecto, manager o lo que sea te da esto:

int factorial(const int n)
{
    return 0;
}

Y además esto:

TEST(funcFactorial, aceptacion)
{
    EXPECT_EQ(factorial(0), 0);
    EXPECT_EQ(factorial(1), 1);
    EXPECT_EQ(factorial(2), 2);
    EXPECT_EQ(factorial(5), 120);
    int n = 20;
    EXPECT_EQ(factorial(n), factorial(n -1)*n);
}

Digamos que con la interface de la función yo puedo compilar, aunque siempre me devolverá 0, pero yo puedo ir haciendo otro trabajo. Tu trabajo seria programar la funcion de manera que pase el test unitario. Programala como quieras mientras no cambies la signatura de la funcion y siempre que el resultado del test sea verde.

Esta estrategia, de crear lo test antes de el codigo que bajo test, se llama test driven development. Este tipo de estrategia, aunque parezca lenta, puede llegar a reducir el tiempo de desarrollo y aumenta la calidad del codigo final, ademas de reducir el tiempo de desarrollo al haber menos fallos.