Tipos de datos. Tabla Hash

Introducción

Una tabla hash es una estructura de datos que permite asociar claves con valores y cuya principal ventaja es una complejidad de inserción y busqueda de O(1) (O(n) en el peor de los casos).

Cuando tenemos la necesidad de almacenar datos en memoria tenemos una serie de opciones (listas enlazadas, arrays, arboles...) cada una de las cuales tienes sus ventajas y sus inconvenientes que normalmente consisten en establecer un compromiso entre espacio en memoria y velocidad.

Una lista enlazada aprovecha completamente el espacio de memoria pero la velocidad de busqueda es lineal, para encontrar un elemento debemos ir recorriendo la lista hasta encontrarlo, en un array reservamos toda la memoria que podríamos por adelantado pero por contra obtenemos un rendimiento de busqueda constante O(1). Los arboles constituyen una variación de las listas enlazadas en las cuales se mejora el rendimiento de busqueda (O(log(n))) a cambio de empeorar el rendimiento de inserción.

Las tablas hash constituyen una forma de obtener un rendimiento (casi) constante controlando la cantidad de memoria que deseamos compromenter, cuanto más pequeña sea la tabla mayor será el impacto sobre el rendimiento de la tabla debido al numero de colisiones.

Aplicaciones Multihilo en Delphi: Metodos de sincronización de Delphi

Introducción

Probablemente la parte más compleja al programar una aplicación con varios hilos es la sincronización entre estos tanto en el acceso a los datos compartidos como en el correcto orden de ejecución que deben seguir.

Uno de los problemas de desarrollar una aplicación multihilo es que son bastante dificiles de depurar puesto que los hilos van entrando y saliendo de ejecución conforme se va acabando su tiempo de ejecución de forma que, al depurar, el depurador va saltando de una linea de código a otra dependiendo de la tarea que vaya estando en la CPU así que siempre hay que tener mucho cuidado al escribir el código por que, si vas a tener que depurarlo, vas a pasarte un buen rato en ello (por no hablar del hecho de que los hilos no tienen porqué, y probablemente no lo haga, ejecutar en el mismo orden y con los mismos tiempos en dos ejecuciones consecutivas).

En esta parte trataremos los objetos de sincronismo más importante que proporciona Delphi mientras que en el siguiente nos centraremos en las primitivas de sincronización que proporciona la API de windows.

Programación multihilo en Delphi. TThread y sincronización básica

Introducción

Si no lo has leido ya, y eres relativamente nuevo al mundo de la programación multihilo es recomendable empezar leyendo la Introducción a la programación multihilo para poder decidir correctamente si realmente es necesario implementar un sistema multihilo o no.

Definiendo nuestro hilo

Delphi facilita mucho la creación de hilos de ejecución proporcionando una clase base que podemos heredar para definir nuestras tareas de ejecución. Esta clase es la clase TThread.

Un ejemplo de una aplicación que usa una tarea para comprimir un archivo.

Clases abstractas e interfaces

Metodos y clases abstractas

En general entendemos por clase totalmente abstracta cualquier clase en la que todos sus metodos son abstractos.

La abstracción de metodos es una técnica muy util para definir patrones de comportamiento de aquellas clases que hereden de la clase que estamos definiendo.

Un metodo abstracto es un metodo de una clase para el cual no se va a proporcionar implementación sino que se espera que que las clases que heredan de ella implementen dicho metodo. En delphi, si se intenta ejecutar un metodo abstracto obtendremos una excepción puesto que realmente no hay un código definido para ese metodo. El ejemplo más clasico de metodo abstracto es algo así:

Introducción a la programación multihilo

Antes de empezar

En este articulo no hay ni una sola linea de código y no esta orientado a enseñar los entresijos especificos de la programación multihilo en este o aquel lenguaje sino a dar una pequeña introducción, centrandose fundamentalmente en el como y el sobre todo en el por qué y en el cuando.

¿Que es la programación multihilo?

En estos tiempos todos los sistemas operativos (excepto quizá los educacionales) son sistemas operativos multitarea, esto quiere decir que pueden ejecutar varias tareas o procesos simulataneamente. Esto no siempre fue así, el ms-dos era un sistema monotarea lo que quiere decir que tan solo una tarea podía ejecutarse en el sistema simultaneamente.

Antes de lanzarnos a explicar la programación multihilo es conveniente hacer un repaso a ciertas caraterísticas de los sitemas operativos.

Delegados en Delphi. Pasando metodos y funciones como parametros.

Que es un delegado

Un delegado (de la palabra inglesa delegate) es un prototipo de función es decir, un esquema que debemos seguir al declarar una función. La palabra delegado proviene (o mejor dicho yo la escuche por primera vez) de C# y probablemente en delphi sería más conveniente referirse a ellas como tipos de funciones.

Los delegados se utilizan fundamentalmente para proporcionar tipado al paso de funciones como parametros a otras funciones o metodos.

Para que sirve un delegado

Si alguien ha programado alguna vez en C sabrá que pasar funciones como parametros esta a la orden del día, estas funciones suelen conocerse con el nombre de funciones de CallBack (algo así como "devuelveme la llamada") e implican que tu estás pasando una función como parametro que quieres que sea invocada cuando dicha función tenga unos ciertos datos preparados.

Una buena parte de las funciones de la API de windows funcionan de esta forma, por ejemplo si observamos la ayuda de la función EnumWindows de la API de windows (kernel32.dll):

La funcion EnumWindows enumera todas las ventans de alto nivel de la pantalla pasando el manejador de cada ventana a una funcion de callback definida por la aplicación. EnumWindows ejecuta hasta que la última ventana sea enumerada o hasta que la función de callback devuelva falso.

    BOOL EnumWindows(

    WNDENUMPROC lpEnumFunc,     // pointer to callback function
    LPARAM lParam       // application-defined value
   );

Uso de memoria en Delphi

Introducción

Hace poco me he encontrado en el trabajo con un programa que estaba haciendo estaba teniendo pérdidas de memoria, no demasiada cada vez pero si lo suficiente como para convertirse en un problema a medio plazo.

Cuando te encuentras un problema de consumo de memoria lo más habitual es mirar el código de la zona en la que piensas que puede estar el problema intentando encontrar el lugar donde consumes memoria que luego no vas a liberar, o bien recurrir a algún programa de monitorización de memoria que te ayude a encontrar dichos problemas (yo no he tenido suerte con ellos).

Puesto que el programa tiene demasiadas lineas de código para hacer una revisión al azar sin saber concretamente donde se producían las perdidas de memoria se me ocurrió que la forma más sencilla de acotar el problema sería ir monitorizando el uso de memoria del programa (esto así dicho suena muy facil pero en realidad no lo es tanto).

Un vistazo al .dpr

Cuando creamos un projecto nuevo en Delphi el IDE automáticamente crea un archivo con extensión dpr (delphi project) y, si el proyecto contiene forms, un archivo dfm (delphi form) por cada form del proyecto (y también una unidad .pas por cada uno).

El archivo con extensión dpr constituye un archivo de proyecto de Delphi. En el se encuentra recogido el código de inicialización de la aplicación así como todas las unidades y formularios del proyecto.

Delphi esta construido sobre el lenguaje de programación pascal, o más concretamente sobre Object Pascal que incluye el paradigma de objetos al lenguaje Pascal. Por ello conserva la organización inicial de pascal en casi su totalidad.

Por más que el IDE de desarrollo nos facilite las cosas y parezca que pasan 'mágicamente', lo cierto es que todo, absolutamente todo, lo que se programa desde delphi acaba siendo un programa de Object Pascal. Por ello lo primero que encontramos en el dpr es la sentencia program NombreDePrograma; seguida de las declaraciónes uses (las unidades y formularios que aparecen en el project viewer (del menu view, project viewer) se leen de aqui) seguido de la declaración de variables, declaración de funciones (normalmente ninguna puesto que el IDE nunca mete funciones aqui) y por último un begin y un end dentro de los cuales se crean los formularios de la aplicación.

Patrones de diseño. Memento Pattern.

Introducción

En muchas ocasiones deseamos guardar el estado de un objeto de forma que podamos recuperar dicho estado en cualquier momento. Un ejemplo muy simple es que vayamos a modificar una serie de parametros del objeto y hacer alguna operación pero deseemos almacenar en que estado estaba ese objeto para poder volver a él en caso de que se produzca una excepción.

En la mayoría de los objetos existe una parte de su estado que queda recogida en variables privadas. Al contrario de lo que se suela pensar una campo es privado no para evitar que alguien pueda modificarlo (que tangencialmente también) sino para indicar al programador que usa la clase que dicho campo no le interesa y no debe tenerlo en cuenta, utilizarlo ni depender en ningún sentido. Si cambiamos dichas variables de privadas a publicas, conseguimos que quien quiere guardar el estado pueda hacerlo leyendo y almacenando los campos pero violamos el concepto anterior.

El patrón memento enfrenta este problema encapsulando la información interna del objeto en una objeto, preferiblemente opaco al exterior.

Patrones de diseño. Facade Pattern

Introducción

El patrón Façade es un patrón de software cuyo objetivo se basa en simplificar o hacer más amigable la complejidad asociada a una librería software.

En ocasiones una librería o serie de librerias contienen una serie de funcionalidades para realizar diversas acciones. Si se analiza, en la gran mayoría de los proyectos de software, se observará que la mayor parte de las llamadas que recibe la librería es a las mismas funciones o a una combinación de ellas. Es decir, existe una gran cantidad de peticiones comunes que suelen ocurrir en el 90% de los casos y que satisfacen las necesidades del cliente de la librería. En estos casos, es convieniente crear un objeto que simplifica el API de la librería, unificando y simplicando ciertos procesos del API. Por supuesto algunos programas todavía querran (y podrán) acceder al viejo API de la librería para utilizar algunas funciones especializadas pero se habrá conseguido simplificar la funcionalidad más comunmente usada de la librería.