Archivo de la etiqueta: programacion

Aprendiendo haskell

Ya hace unos meses que, con tiempo que dispongo, estoy aprendiendo haskell. El motivo principal es que quería empezar con un lenguaje que fuera completamente distinto a los que ya conozco.

Confieso que de momento me parece todo un galimatías. Si bien llego a resolver algunos problemas sencillos, aún me pierdo con cosas medianamente complejas.

Además, para ir aprendiendo e ir estrujándome los sesos utilizo codewars para ir resolviendo ejercicios. Creo que es un buen modo para ir tomando contacto con el lenguaje.

¿Qué me aporta haskell?

La verdad es que no lo estoy estudiando porque sí. El objetivo es poder aprender nuevos mecanismos para afrontar los problemas. Haskell te obliga a afrontarlos desde una perspectiva completamente diferente a lo que es habitual en los lenguajes imperativos. Con ello espero que a futuro pueda incorporar nuevas formas para resolver problemas a mi día a día (siempre que valgan la pena).

¿Por qué haskell?

Porque al ser un lenguaje funcional puro me obliga a desconectar totalmente de lo que ya sé. Hay otros lenguajes funcionales, pero no llegan a la pureza de haskell¹ lo que me podría permitir desviarme de la intención de aprender programación funcional.

¿Qué haré con él?

Cuando tenga más claro como funciona y no me pierda tanto me pondré con yesod, un framework para desarrollo web. Creo que será toda una experiencia.

¿Y después?

Una vez que ya tenga haskell dominado espero poder ponerme con Rust. La verdad es que de un tiempo a esta parte ando muy desencantado con C. Cada día me parece peor lenguaje de programación, pero eso ya será otro artículo.

Notas

  1. Probablemente haya más lenguajes funcionales puros, pero haskell es de los que tiene la comunidad más amplia y, por tanto, en la que es más fácil encontrar documentación.

Control de errores

Uno de los grandes problemas al programar es realizar el control de los errores. Por diversos motivos me ha tocado hacer un trabajo de estudio sobre qué opciones tenemos para realizar el control de los errores de una aplicación.

La verdad es que hubiese estado muy bien hacer una tormenta de ideas al respecto, pero en estos momentos estamos todos demasiado atareados.

El siguiente texto, sin pretender ser una guía exhaustiva de lo que es el control de errores, sí busca poner un punto de partida para todo aquel que quiera ver qué mecanismos hay para este fin.

Seguir leyendo Control de errores

Tratamiento de cadenas en C

Cuando empezamos a programar en C una de las cosas que probablemente más nos cuesta controlar es el tratamiento de cadenas.

El lenguaje C es de bastante bajo nivel, por lo que sus tipos de datos básicos son muy cercanos a lo que la máquina puede utilizar. Los ordenadores no entienden de cadenas, pero sí de direcciones de memoria. De hecho, no existe un tipo de cadena, sino que se usan arrays de bytes. Y lo mejor de todo, ¡en C es el programador el que debe conocer la longitud del array! (cuanto bien, y a la vez cuánto mal, han hecho los lenguajes modernos).

Todas las funciones del estándar de C presuponen que una cadena es un array de bytes donde el último carácter es un nulo.

No voy a entrar en más detalles sobre que son las cadenas. Si quieres aprender cómo se programa con ellas puedes leer Cadenas de caracteres del manual Programación en C de  wikibooks.

Quien más y quien menos habrá visto que muchos problemas de seguridad en bibliotecas en C viene precisamente del tratamiento de cadenas. Casi se podría decir que si tienes que hacer un programa que tenga que manejar cadenas es aconsejable que mires cualquier otra cosa que no sea C. Aún así, esto no siempre será posible.

En el lugar en el que trabajo hemos empezado a cambiar el modo en que utilizamos las cadenas. Para facilitar su uso y reducir la cantidad de errores que pueden producirse, hemos creado un nuevo tipo de cadena. Bueno, se parece más a un StringBuilder de java. Las motivaciones son varias:

  • Queremos un tratamiento de cadenas más rápido (tener que recorrer una cadena cada vez que quieres conocer su longitud no es óptimo).
  • Queremos poder trabajar con cadenas sin preocuparnos por reasignar constantemente memoria. ¿Habéis probado un strcat cuando estás usando arrays y el buffer de destino es más pequeño que la cadena a concatenar?
  • Para ciertas operatorias queremos poder tener cadenas con caracteres nulos. Las cadenas de C no se llevan bien con esto, pero nosotros creamos cadenas para mandar a dispositivos que no sólo aceptan el nulo, sino que ciertas operaciones lo requieren. Con las funciones estándar sería muy complicado esto.

Personalmente no creo que seamos los primeros en hacer algo así; no tengo la más mínima duda de que hay muchas personas con los mismos problemas.

Las ventajas de usar esta biblioteca son inmediatas:

  • Simplificamos el código por no tener que preocuparnos en si hay o no espacio para almacenar la cadena y en la gestión de este espacio.
  • Minimizamos errores pues no nos pasaremos nunca del buffer (siempre podemos quedarnos sin memoria).
  • Agilizamos el desarrollo al poder escribir directamente código que haga lo que queremos (es una consecuencia del primer punto).
  • Se pueden optimizar ciertas operaciones. Esto se debe a que no hay que estar constantemente recorriendo cadenas para medirlas o que al «liberar» una cadena, no hacemos free y malloc, sino que marcamos la cadena como de longitud 0 (que es más rápido y permite aprovechar la memoria).

¡Mucho ojo con esto! Que en el día a día de mi trabajo esta haya sido una buena solución no significa que lo sea para todos los casos. Siempre hay que evaluar convenientemente cada situación antes de decantarse por una u otra solución.

Pseudo lambdas con C

Últimamente se lleva mucho el tema de las funciones lambda y los closures en los lenguajes modernos. Un ejemplo es que en C++, desde la versión de 2011, ya las incorpora. Igualmente, otros lenguajes, como Ruby, Groovy o Rust ya han sido diseñados con esta característica.

Advertencia: el código que vamos a mostrar a continuación hace uso de extensiones de GNU C. Para ser exactos, hace uso de Statement Expressions y de Nested Functions. Estas extensiones solo son soportadas por unos pocos compiladores a parte de GNU C (ver Compiler support of GNU Statement Expressions en stackoverflow).

Aunque en C no existe nada parecido es factible simularlo. Todo sea dicho, el código puede ser muy feo. En el siguiente ejemplo tenemos una función que recorre un conjunto de elementos. Esta función la llamamos proccess. Por cada elemento procesado llama a una función de callback. Lo normal es crear la función de callback a parte, lo que hace que en ciertos casos sea incómodo el mantenimiento del código.

Otra opción es declarar la función de callback in situ justo en el momento que la necesitamos:

Como puede verse, nos aprovechamos de ‘({‘ y ‘})’ para declarar un bloque de código que devuelve el valor de la última expresión para crear nuestra función de callback. Como en este caso el nombre no nos importa, la llamamos ‘_’. Lo mejor de todo es que podemos repetir este nombre sin que por ello suponga que vaya a haber conflicto en la compilación ni en la ejecución.

Actualización 1: incluimos advertencia sobre compiladores.

Concurso de C «a pelo»

Recientemente surgió en una newsletter de O’Reilly un concurso que me pareció bastante curioso. Las bases eran las siguientes:

It seems like a new language is spawned every day, but the old tried-and-true warriors of the code world continue to soldier on. This week, the specification for C++ version 14 was frozen, and it includes such features as enhanced lambda expressions (because all the cool languages are doing it). In honor of this momentous event, we’re running a little contest to test your chops with the bare C. Sure, anyone can create awesome code using all the libraries that modern operating systems come with, but what can you do close to the metal?

Your challenge is to create a nontrivially useful application that will compile on a Linux system using the following command:

 gcc -nostdlib -o sample sample.c startstub.S

startstub.S is an i386 assembler file that can call main() without the standard libraries and can be downloaded here. You need to have a function main defined as «int main()» that can return a value, which will end up in $?. Only C is allowed, no assembler or other funny business. Entries will be judged on two criteria: binary size and functionality of the program. For reference, a program that does nothing weighs in at 1502 bytes.

Básicamente dice que hay que hacer un programa en C, que no va a poder enlazar con biblioteca de funciones alguna (no hay libc) y que no se puede hacer uso de ensamblador. Esto último es importante, porque con esta restricción se pierde la capacidad de hacer llamadas al sistema: no se puede reservar memoria con malloc, ni leer ni escribir en disco, etc. Eso sí, el programa debe tener alguna utilidad y te dicen que puede devolver un valor que será podrá ser consultado con $? (variable de la shell con el resultado del último programa ejecutado). Eso sí, el startstub.S que suministran no permite dicho uso (¿despiste quizá?).

Estas premisas tan restrictivas me animaron a tratar de crear algo para el concurso. Tras varias ideas descartadas decidí hacer una aplicación que devolviese la posición de una palabra en una lista de palabras (no parece muy útil) y que con una opción permitiese devolver la palabra de la lista más parecida a la buscada (puede resultar algo más útil).

El problema es que con lo suministrado por la gente de O’Reilly, la función main no recibe argumentos. Así que no tenemos un mecanismo sencillo para comprobar los parámetros.

La solución al problema anterior es tener en cuenta que Linux, cuando ejecuta un programa y pasa le pasa el control deja en la cima de la pila argc, luego argv y después env. Como la función _start suministrada no mueve los punteros de la pila, main tendrá esos mismos datos. Así que sólo hay que buscar un mecanismo para obtener un puntero a la cima de la pila.

En la arquitectura i386, los argumentos de las funciones se pasan por pila. Así, si tenemos una función que sólo acepta un parámetro, en el momento en que entramos en la función nos encontraremos esto en la cima de la pila:

0x000000 Dirección de Retorno
0x000004 Parámetro

Por tanto, la dirección de memoria del primer parámetro será una posición en la pila. En este caso sabemos que se correspondería con argc.

El problema es que en las arquitecturas de 64 bits, no se comporta de este modo: los 6 primeros parámetros son registros de procesador. En este caso, si es una arquitectura de este tipo, creamos una función que acepta 7 parámetros. Los seis primeros que serán registros (y los ignoramos) y el séptimo que ya se encuentra en la pila.

El resto del programa ya no tiene más misterios y lo podéis ver a continuación:

Curiosidades de C++

Ayer trasteando con el compilador de C++ descubrí una cosa nueva sobre cómo funciona por dentro.

Si compilamos el siguiente programa y lo ejecutamos veremos que falla con un bonito SIGSEGV:

El motivo es que, para empezar, hay dos estructuras que son diferentes pero se llaman igual. El constructor de dichas estructuras no deja de ser una función, por lo que en cada fichero objeto se generará una función para construir la estructura. Sí, la función se llamará igual en ambos objetos.

Cuando enlazamos se queda con la primera función que encuentre (en este caso con la de a.cpp). Así que cuando desde run_example_b se trata de instanciar la estructura lo hace con el constructor de a.cpp.

Hasta ayer por la tarde no caí en porque esto funciona así, pero es bastante lógico. Hay muchas clases en las bibliotecas estándar (y de terceros) cuyos constructores están implementados en la propia cabecera. Esto significa que cada fuente que tengamos tendrá su propia implementación del constructor y luego, al enlazar, se reduce a sólo uno.

Si el ejemplo anterior lo compilamos todo con ‘-O2’, el constructor lo convierte en inline para optimizar y funciona correctamente.

Nota mental: hay que mejorar los nombres de funciones in clases según su utilidad y contexto (debe ser más semántico).

Transformaciones AST para importar clases de IDL

En la anterior entraba hablaba un poco sobre las transformaciones AST de Groovy y que me maravillaban (y si esto último no lo dije, lo digo ahora). Como me gustan y las veo útiles decidí ponerlas en práctica para un uso real.

En donde trabajo se utiliza un lenguaje de programación llamado IDL. Este lenguaje se utilizan en muchos entornos de investigación y para ser sinceros se haría un favor al mundo amputándole las manos a la persona o personas que lo diseñó/aron (pero dejemos esto para un posible futuro artículo). En IDL se pueden crear funciones y procedimientos o se puede crear clases con métodos y atributos. Cuando se necesita ofrecer a otro lenguaje de las funcionalidades que hemos creado en IDL se hace uso siempre de clases y objetos. Además provee de una herramientas denominada Export Bridge Assistant (EBA) para facilitar la tarea de generar los bindings del lenguaje destino. Debo decir que me EBA hace cierto trabajo por el programador, concretamente genera una clase en java o .Net con los métodos seleccionados, pero en el caso de Java no hace distinción de los tipos de datos. Para él solo existe el JIDLNumber, pero está prohibido por el programador su uso, sino que debes utilizar JIDLFloat, JIDLLong, etc. Además, estos tipos de datos no son nativos de Java lo que supone un sobreesfuerzo para el programador.

En esta situación se me ocurrió crear una transformación AST que generase el código de los métodos usando datos nativos de Java. En lugar de llamar a EBA para generar el binding se crea una clase de esta forma:

1
2
3
4
5
@IDLClass(idlclass="CLASE_DE_IDL")
class MiClaseEnJava extends JIDLObject {
   @IDLFunction(name="FUNCION_IDL")
   float miFuncion(float a, float b, String cadena) {}
}

Durante la compilación de la clase se detecta la nota IDLClass y se pasa el control a la transformación AST que añade un constructor por defecto necesario para los objetos que heredan de JIDLObject. Además se busca de nota IDLFunction y cuando se encuentra se interpretan los parámetros para generar el código con las transformaciones de tipos necesarias.

Sinceramente creo que esto es más óptimo que hacer uso de EBA, ya que de todos modos me termino creando métodos que realizan la transformación de tipos y de este modo me ahorro dicho trabajo.

Lo que más me ha costado es entender como funciona la generación de código ya que se basa en la estructura del compilador. Concretamente me ha constado 1 semana hacer la transformación.

En cuanto pueda publicaré el código para que lo pueda utilizar quien quiera, que seguro que mal no hará.

Haciendo memoria

Esta semana he recordado uno de mis viejos proyectos de cuando era más joven (sería el año 97). En aquel momento tenía en mente la creación de un lenguaje que pudiese ser modificado en tiempo de compilación. Con esto me refiero a que pudiesen crearse reglas que permitieran modificar el cómo este compilaba o añadiese nuevas posibilidades al lenguaje.

En aquel momento yo no tenía conocimiento alguno de lenguajes, gramáticas o compiladores y el único curso que vi fue el de la revista Solo Programadores de varios años atrás y, la verdad, no me resolvió ninguna duda (esto se debe a que entonces no solía leer tanto y miraba solo por encima las cosas).

El caso es que me he encontrado que ya lo han inventado. En Groovy existe una característica denominada transformaciones AST que permite modificar las reglas de compilación.  Debo reconocer que es una característica tan chula como difícil de utilizar (todo hay que decirlo).

En estos momentos me encuentro estudiando la documentación para ponerme a hacer pruebas y comprobar qué tal funciona. La verdad es que permite hacer cosas tan increíbles como Groovy++, que es un optimizador de Groovy (lo que hace es eliminar algunas características de Groovy para acelerar la ejecución de las aplicaciones).

He podido encontrar una gran cantidad de ejemplo y la verdad es que me sorprenden mucho. Por ejemplo se pueden automatizar patrones de diseño con este sistema tal y como se hace con la transformación Bindable. Ésta convierte un atributo de clase en un sistema que permite monitorizar los cambios del mismo (patron ). De este modo si tenemos algo como:

1
2
3
class ClaseDeEjemplo {
    @Bindable String prop
}

Se transformará de forma automática en:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class ClaseDeEjemplo {
    private String prop
    PropertyChangeSupport pcs = new PropertyChangeSupport(this);
    public void addPropertyChangeListener(PropertyChangeListener l) {
        pcs.add(l);
    }
 
    public void removePropertyChangeListener(PropertyChangeListener l) {
        pcs.remove(l);
    }
 
    public String getProp() {
        return prop;
    }
 
    public void setProp(String prop) {
        pcs.firePropertyChanged("prop", this.prop, this.prop = prop);
    }
}

Con lo que evitamos tener que escribir un gran número de líneas de código. Sinceramente me parece un gran avance.

A vueltas con las plantillas

Ando haciendo pruebas últimamente con C++ y hay algo que ahora no soy capaz de hacer, que es que elija entre un método u otro dependiendo de si lo que se le pasa por parámetro es una función o un functor.

Concretamente tengo algo como esto:

template<typename T, typename Proxy = queue_proxy<T> >
class channel
{
public:
	template<typename Result>
	channel<Result, typename Proxy::template bind<Result>::type>
	operator>>(Result (&receiver)(T))
	{
		channel<Result, typename Proxy::template bind<Result>::type> out_channel;
		threads.push_back(new boost::thread(create_stream_channel_thread(*this, out_channel, receiver)));
		return channel<Result, typename Proxy::template bind<Result>::type>(out_channel);
	}
};

La idea es que este código permite hacer algo como lo siguiente:

int fac(int x)
{
	if(x < 1) return 1;
	return x * fac(x-1);
}
 
void show(int x)
{
	std::cout << x << std::endl;
}
 
/* some code here */
 
channel<int> ch;
 
/* Se redirige el canal a fac y la salida del factorial a show */
ch >> fac >> show;
 
/* more code here */

Sí, el código se parece mucho a Axum de Microsoft, que la idea es crear algo parecido para C++.

El caso es que el operador funciona bien cuando se pasan funciones, pero no funciona si le paso un functor, como podría ser el caso siguiente:

class functor
{
public:
	functor() {}
 
	int operator()(int a)
	{
		/* do something interesting */
	}
};
 
/* some code here */
 
channel<int> ch;
ch >> functor() >> show;

La cosa es que no sé como hacer para detectar que se me pasa un functor y qué parametros son los que tiene, aunque aún tengo que hacer alguna prueba más antes de dar por imposible la tarea.

Plantillas en C++

Recuerdo cuando empecé a aprender C++ que la cosa que menos entendía era el uso de plantillas. Debo reconocer que me ha costado mucho comprender como funciona porque era algo completamente diferente a lo que hasta entonces había visto.

Por otro lado, hemos visto en los últimos tiempos como gran cantidad de arquitecturas han copiado el modelo para implementarlo a su modo. Aquí es donde vemos los genéricos de Java y de .Net. El problema es que no tienen ni de cerca la misma potencia que el sistema de C++, pero que como ventaja consumen menos espacio de ejecutable.

Para entrar un poco en materia, comentar que las plantillas de C++ son como documentos en los que dejamos lineas en blanco y luego las rellenamos cuando ya sabemos qué queremos poner en ahí. Pero en C++ no ha líneas en blanco, estas tienen nombre.

La principal ventaja de este sistema es que permite programar clases genéricas, como pueda ser una clase lista que automáticamente se adapte al tipo que debe contener. La segunda ventaja es el rendimiento, por el mismo motivo anterior.

Para empezar a ver un poco como va la cosa vamos a ver un ejemplo sencillo de plantilla:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
template<typename T, int S>
class array
{
private:
   T *ptr;
 
public:
   array()
   {
      ptr = new T[S];
   }
 
   T& operator[](int idx)
   {
      return T[idx];
   }
 
   int size()
   {
      return S;
   }
};
//</typename>

Como vemos, hemos utilizado la palabra reservada template para indicar que se trata de una plantilla y luego, entre los símbolos < y > hemos introducido la lista de elementos de la plantilla. Estos elementos son los tipos y nombres de los valores a sustituir. En este caso son T de tipo typename y S de tipo int. Esto significa que cada vez que dentro de la clase aparezca T deberá sustituirse por su corresponditente valor pasado en la plantilla y que necesariamente deberá ser un tipo de dato (por ejemplo un int, una clase, etc.) y que cada vez que aparezca S deberá sustituirse por su valor que deberá ser un número entero. Para utilizar la plantilla sólo deberemos hacer lo siguiente:

1
2
3
4
5
6
7
8
9
10
int main(void)
{
   using namespace std;
 
   array<int , 5> a;
   cout < < "Tamaño del array: " << a.size() << endl;
   a[1] = 5;
 
   return 0;
}

Como vemos, lo único que hemos hecho ha sido añadir al nombre del la clase la lista de argumentos. En este caso concreto, deberá devolver que el tamaño es 5, que es el indicado en el parámetro de la plantilla.

Si nos fijamos en bibliotecas como STL o Boost, hacen un uso intensivo de las plantillas. El principal motivo es que C++ está optimizado para funcionar con plantillas, así que se prefieren al uso de mecanismos como la herencia. Además, la herencia hace que las llamadas a métodos sean más lentos, por lo que también se evita. Es en este momento cuando nos podemos preguntar el cómo hace C++ entonces para garantizar que se implementan ciertas funcionalidades. Por ejemplo, si queremos tener una lista ordenada, nos interesa que los elementos de la lista puedan compararse entre ellos con el operador <=. Pues la respuesta es sencilla: en la clase de plantilla simplemente utilizamos ese método y en tiempo de compilación se comprueba si está o no. Por ejemplo:

1
2
3
4
5
6
template<typename T>
T& mayor(T& a, T& b)
{
   return a >= b ? a : b;
}
//</typename>

Hemos creado una función mayor que devuelve el mayor de dos elementos de tipo T. Los elementos de tipo T deben sobrecargar el operador >= para que funcione. Como se ve, no es necesario hacer herencia de ningún tipo, el compilador detecta automáticamente si está o no sobrecargado y dará el correspondiente error en caso necesario (si miramos el caso de Java o de .Net veremos como sí es necesario hacer herencia para que el mecanismo de genéricos funcione de este modo).

Debo decir que el tema de las plantillas está muy bien y se puede hacer muchas cosas interesantes, como la clase array, que funciona igual que un array y que tiene un rendimiento muy parecido (benditos métodos inline de C++).

Otro día, seguiré hablando sobre plantillas, que dan para mucho.