Fernando Briano, de Picando Código, está con un artículo muy interesante hoy sobre StringBuilders y StringBuffers de Java. El artículo describe el por qué un desarrollador querría hacer uso de éstos en vez de los operadores sobrecargados de String (como “+”) para concatenar Strings.

La clase string de C++, definida dentro del cabezal <string> y bajo el namespace std, también provee un operador sobrecargado de “+” para concatenar instancias de strings pero, al igual que en Java, existen circunstancias en las cuales es mejor utilizar un buffer para concatenar, por ejemplo, para evitar crear muchos objetos temporales en el stack (nótese que a diferencia de Java, en C++ podemos crear objetos tanto en el Stack como en el Heap.).

La clase stringstream, también del namespace std pero definida en el cabezal <sstream> provee una funcionalidad similar al StringBuilder de Java, pero haciendo uso del operador de inserción de flujos de C++ (<<). Los stringstreams permiten insertar cualquier tipo de dato dentro del flujo. Todos serán convertidos automáticamente a strings y concatenados.

A continuación un ejemplo:

#include <iostream>
using std::cout;
using std::endl;

#include <sstream>
using std::stringstream;

int main(int argv, char* argv[])
{
    // Creamos un stringstream y concatenamos varias constantes:
    stringstream ss;
    ss << "Picando" << " " << "Codigo" << "; btw PI = " << 3.14159;

    // Imprimimos el string en la salida estándar:
   cout << ss.str() << endl;

   return 0;
}

A diferencia de Java, los stringstreams también pueden utilizarse para tokenizar strings. En este caso seteamos el string directamente y luego utilizamos el operador de extracción de flujo (>>) para obtener los tokens:

#include <sstream>
using std::stringstream;

int main(int argc, char* argv[])
{
    stringstream ss;
    ss.str("Tokenizame 2 4.0");

    string s;
    int i;
    double d;

    // Extrae, convierte a los tipos apropiados y asigna, todo en una sola línea:
    ss >> s >> i >> d;
    return 0;
}

Interesante, ¿no? Gran parte de la flexibilidad de los stringstreams viene de la posibilidad de C++ de sobrecargar operadores, lo cual permite simplificar la lectura de las rutinas que trabajan con entrada salida de flujos, ya sea E/S a la terminal o E/S a un buffer de strings.

Ayer leía en Slashdot sobre la historia del Port de Death Rally, un juego desarrollado por una empresa ya difunta llamada Apogee y del cual los derechos son ahora de la Finlandesa Remedy Edit: Resulta que la Finlandesa Remedy desarrolló el Juego y Apogee fue solamente el Publisher.

Extraído del artículo:

“La plataforma original era DOS, Watcom C, y un extensor de DOS estilo DOS4GW. El extensor básicamente significaba que podías utilizar más de 640k de memoria, y no necesitarías código extraño para datos mayores a 64k.

El juego desplegaba en los modos gráficos VESA 640×480 y MCGA 320×200, todos con paletas de 8 bits; No había color real en ninguna parte. También habían algunos trucos de cambios de paleta cada cuadro con los cuales los emuladores tienen problemas.

El código fuente era mayoritariamente C puro, con un par de docenas de funciones assembly embebidas. Un par de subsistemas se encontraban faltantes, específicamente audio y red, los cuales tendrían que ser reemplazados completamente de todos modos, al igual que un archivo para el cual el código fuente se había perdido y solo un objeto compilado estaba disponible.”

La historia cuenta los detalles del port; En general tiene mucho que ver con los problemas que uno suele encontrarse cuando desea adaptar una aplicación DOS a Windows. Uno de los problemas más comunes es que en DOS, uno podía programar a muy bajo nivel, haciendo a un lado al Sistema Operativo y trabajando directamente sobre el Hardware.

Una solución que me llamó la atención consistió en como resolver el problema de que para dibujar en la pantalla, el programa escribía en memoria de video directamente (en la dirección 0xa000). La solución fue, en vez de rehacer todo este código, crear una array del tamaño apropiado, almacenar un puntero global (llamado g0xa000) y reemplazar las escrituras.

Pueden seguir leyendo los detalles del port en el artículo original y también pueden descargar el Death Rally gratis para Windows (XP, Vista, 7) desde la página de Remedy.

Enconté mediante Reddit un post en Stack Overflow que explica en términos sencillos en qué consiste la notación “Big-O”, utilizada para representar la complejidad de un algoritmo.

Traduzco solo una parte del post aquí, les recomiendo leer el post completo si es que te encuentras en duda o necesitas repasar en qué consiste esta notación.

La notación Big-O es una representación relativa de la complejidad de un algoritmo.

Hay algunas palabras importantes deliberadamente elejidas en esta oración:

• relativa: únicamente puedes comparar manzanas con manzanas. No puedes comparar un algoritmo que hace multiplicación aritmética con uno que ordena una lista de enteros. No obstante, [comparar] dos algoritmos que hacen operaciones aritmeticas (uno multiplicación y otro suma) te dirá algo significativo.
• representación: Big-O (en su forma más simple) reduce la comparación entre algoritmos a una única variable. Esa variable es elegida basandose en observaciones y supuestos. Por ejemplo, [los] algoritmos para ordenar son típicamente comparados en base a operaciones de comparación (comparar dos nodos para determinar su orden relativo). Esto asume que comparar es costoso. ¿Pero qué si comparar es barato e intercambiar costoso? Cambia la comparación; y
• complejidad: si me toma un segundo ordenar 10.000 elementos, ¿cuánto me llevará ordenar un millón? La complejidad, en esta instancia, es una medida relativa de algo más.

Continuar leyendo en Stack Overflow…

Supongamos que tenemos dos listas a y b de Python y queremos calcular una lista d tal que:

d = a – b #diferencia de conjuntos.

Utilizando las construcciones funcionales de Python (en particular List Comprehension), resulta muy sencillo:

d = [x for x in a if x not in b]

Vean como la construcción del lenguaje prácticamente se lee como la definición formal de diferencia de conjuntos: “d es igual a x para todo x que pertenece a a y x no pertenece a b“.

Si comparamos esto con el equivalente imperativo, es fácil ver que estamos expresando mediante el lenguaje lo que queremos que se haga y no cómo hacerlo exactamente.

Esta sutileza nos permite ahorrar mucho código y ser más productivos desarrollando aplicaciones cuando no es crítico el mantener el control sobre cada instrucción exacta a ser ejecutada.

¿Qué otros ejemplos interesantes de manejo de listas sueles utilizar?

El MIT ha publicado en Internet las trasparencias de su curso “Practical Programming in C”, correspondiente a Enero del 2010.

El curso se compone de 14 trasparencias (una por lección), todas disponibles gratuitamente en el siguiente link:

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-087-practical-programming-in-c-january-iap-2010/lecture-notes/

Yo leí hasta la lección 7 y pude apreciar como el material comienza con lo básico pero rápidamente comienza a cubrir mucho terreno, incluyendo estructuras de datos y algoritmos.

Las últimas lecciones incluyen programación multihilo, concurrencia y comunicación entre procesos sobre Linux.

¡Muy recomendable!

A modo de prueba de concepto aproveché un ratito libre para implementar uno de los trabajos obligatorios que asignamos a los alumnos en una de mis materias en Facultad.

El trabajo consiste en desarrollar un programa que dibuja un conjunto de Fractales mediante un sistema iterativo de funciones. La siguiente imagen muestra el programa corriendo para una configuración que corresponde a una Hoja de Helecho:

Hoja de Helecho. Los cálculos del fractal fueron realizados en Cython y el resultado fue dibujado con Pygame.

La optimización principal para el Fractal consistió en reemplazar el uso de una lista de Python de 10.000 elementos (utilizada para almacenar los puntos calculados) por un array de C. Por menos que esto parezca, el evitar tener que usar la lista de Python mejoró la performance general del cálculo en un 11%, aproximadamente.

Dentro de todo, 11% no está mal, sobre todo si tenemos en cuenta que el único cambio fue la declaración de la lista (y escribir un archivo de setup). El compilador de Cython se encargó del resto.

Creo que por más que se encuentre en sus primeras versiones, Cython ofrece mucho potencial para optimizar aplicaciones Python. Todo lo que uno debe hacer es dedicar algo de tiempo para encontrar las porciones críticas en performance en su código, anotar las variables apropiadas con tipos de datos C, y dejar que Cython se encargue del resto.

Hace ya varios años, por allá, por el 13 de Marzo de 2006, publicaba en uno de mis viejos blogs discontinuados un programa Java que implementaba un servidor Web sencillo.

Por aquellos tiempos había estado leyendo sobre cómo funcionaba el protocolo HTTP. HTTP me había parecido que era extremadamente sencillo, sobre todo considerando que es una de las tecnologías fundamentales de Internet, fue as qué decidí probar si realmente era tan sencillo como parecía haciendo un programa prueba de concepto.

Este artículo es una copia del post realizado en el 2006 en el cual se anunciaba el proyecto, se publicaba un archivo zip conteniendo el programa y se explicaba cómo usarlo.

De momento únicamente tengo el código compilado. Si a alguien le resulta interesante, puedo buscar el fuente y publicarlo aquí. Si no quieren leer todo el artículo, encontrarán la descarga sobre el final del mismo.

Sin más, dejo el resto del post original del 2006 a continuación.

Introducción

Trivial HTTP Daemon o thttpd por conveniencia es un servidor de páginas web escrito 100% en Java.

Sus objetivos de diseño son ofrecer un médio para compartir información, el cual sea seguro, fácil de instalar y configurar, así como altamente potable entre distintos sistemas operativos y arquitecturas.

thttpd puede verse como un servidor de páginas “plug and play”, se descomprime, se configura y se usa. Su bajo acoplamiento permite compartir archivos de cualquier tipo en cuestión de minutos y ser eliminado rápidamente cuando no es más necesario. Ideal para ser utilizado cuando todo lo demás falla.

Su uso es gratuito pero se encuentra sujeto a los términos contrato de licencia adjuntos en en archivo release notes.txt

Requerimientos

A pesar de ser diseñado para ser una aplicación al estilo “plug and play”, el servidor presenta una serie de requerimientos de configuración para su uso.

• Java Rutime Environment, versión 1.5.0. El servidor fue escrito y probado utilizando la JDK 1.5.0 update 6.
• Configuración de cortafuegos (firewall) si existe uno, para permitir aceptar y responder a conexiones entrantes.
• Configuración de la aplicación!!

Configuración

Para configurar el servidor basta con editar el archivo thttpd.conf incluido con la aplicación. Puede editarse utilizando tu editor favorito (excepto notepad o word).

El archivo de configuración se encuentra completamente documentado, por lo cual los usuarios encontrarán muy sencilla la tarea de editar los valores para ajustarse a sus necesidades únicas.

Los archivos de configuración pueden moverse de un equipo a otro para agilizar el proceso de puesta en marcha.

Iniciando el Servidor

Para inciar el servidor debemos asegurarnos que el archivo de configuración thttpd.conf se encuentra en el mismo directorio o carpeta que el archivo trivialhttpd.jar. Inicia una consola, ve a esa carpeta y ejecuta el comando

java -jar trivialhttpd.jar

ya esta!! El servidor escucha en el puerto configurado en el archivo de configuración. Para acceder a él utilizamos cualquier navegador e ingresamos la dirección del servidor seguida de :<#puerto>.

Saliendo del Servidor

Para salir, se debe seleccionar la consola que inició el servidor y presionar Control + C. De momento no hay otra forma de terminar el servidor que esta.

Tipos de Archivos Soportados

La versión 1.0 del servidor thttpd solo se soportaban archivos de caracteres, es decir, de extensión .txt, .rtf, .html, etc.

La versión del servidor thttpd 2.0 soporta archivos de cualquier tipo, incluyendo imagenes, sonidos y música, entre otros.

Acceso a Archivos

El servidor necesita que sea especificado lo que se conoce como una raíz de documentos (document root), la cual representa la raíz a partir de la cual se servirán todos los archivos (recursivamente hacia abajo en la jerarquía).

La raíz de documentos es una ruta que se agregar a los pedidos de archivos para permitir su localización en el sistema de archivos del equipo que esta ejecutando la aplicación.

Supón que thttpd esta escuchando en un equipo de nombre “Archivos”, en el puerto 3307, el cual contiene un archivo de nombre invitados.txt.

Para acceder a este archivo abrimos un navegador de Internet, como Mozilla Firefox por ejemplo, e ingresamos la dirección http://Archivos:3307/invitados.txt

El servidor “Archivos” tomará /invitados.txt y se lo agregará a la raíz de documentos. Luego, pedirá a su sistema operativo dicho archivo y lo mandará a través de la red a quien lo solicitó. (Nota que de esta manera obtenemos un subsistema de seguridad “gratis” por así decirlo. Hablaremos de esto en la siguiente sección.)

En caso de que un archivo no sea encontrado, el servidor enviará un mensaje de 404 – File Not Found. No se soportan espacios en los nombres de archivo o en los directorios que los contienen.

El servidor también puede accederse mediante su dirección IP.

Seguridad

Hasta la versión actual del servidor thttpd no se ha desarrollado un subsitema propio de seguridad, sino que se utiliza el subsistema del sistema operativo que alberga la aplicación.

Esto funciona de la siguiente manera: como la aplicación debe ejecutar en nombre de un usuario específico (quien inició la aplicación) y como la aplicación debe pedir los archivos al sistema operativo, los archivos que no pueden ser accedidos por el usuario, tampoco pueden ser servidos por el servidor.

A pesar de que este enfoque nos lleva a un esquema de seguridad fuerte en sistemas Unix y Linux, también puede lleva a problemas de seguridad en sistemas Microsoft Windows. La mejor práctica de seguridad es no colocar bajo la raíz de documentos los archivos que no quieres compartir. Consecuentemente, no compartas las raices de los sistemas de archivos (/ en Unix/Linux o C:\ en Microsoft Windows).

Tampoco es recomendable ejecutar el servidor con permisos de administrador.

Autor, Créditos

Trivial HTTP Daemon, thttpd, diseñado y desarrollado por Alejandro Segovia.

Descarga

>> Descarga Trivial HTTP Daemon (11.1 KB)

Hoy estuve revisando cómo crear bibliotecas estáticas para programas C y C++, de forma de poder “empaquetar” código objeto en forma de una Biblioteca reutilizable.

(An English version of this Post can be found here.)

Crear una biblioteca estática es muy sencillo y consiste, a grandes razgos, en los siguientes dos pasos:

1. Compilar el código fuente en código objeto.
2. Recopilar todo el código objeto en un archivo que representa la Biblioteca.

Supongamos que tenemos un programa C sencillo como el que se presenta a continación:

/** algebra.h **/

#ifndef ALGEBRA_H
#define ALGEBRA_H

typedef struct
{
	float x, y, z;
} Vec3;

void vec3Init(Vec3* v, float x, float y, float z);

float dot(Vec3* a, Vec3* b);

#endif //ALGEBRA_H

/** algebra.c **/

#include "algebra.h"

void vec3Init(Vec3* v, float x, float y, float z)
{
	v->x = x;
	v->y = y;
	v->z = z;
}

float dot(Vec3* a, Vec3* b)
{
	return a->x * b->x + a->y * b->y + a->z * b->z;
}

Crearemos una biblioteca estática con los siguientes dos comandos:

gcc -static -c algebra.c -o algebra.o
ar -rcs libalgebra.a algebra.o

Por favor nota que hemos denominados nuestra Biblioteca “libalgebra.a”. Esto no es casualidad; El nombre debe comenzar con “lib” y terminar con “.a” para que pueda ser linkeado con gcc en un programa.

Ahora que se encuentra pronta nuestra Biblioteca, podemos redistribuirla junto con el header algebra.h para que otros programadores puedan hacer uso de ella en sus programas.

Para ilustrar esto desarrollamos un pequeño programa C que incluya el header y sea linkeado contra nuestra Biblioteca:

#include <stdio.h> /* printf */
#include "algebra.h" /* Incluimos nuestro header */

int main()
{
	Vec3 a;
	Vec3 b;
	vec3Init(&a, 1.0f, 2.0f, 3.0f);
	vec3Init(&b, 3.0f, 2.0f, 1.0f);
	printf("<a,b> = %.2f\n", dot(&a,&b));
}

Nota como hacemos un uso liberal de tipos de datos y funciones que habíamos definido en nuestra Biblioteca. Para que este programa compile, solo necesitamos que el header esté presente; Para linkearlo, debemos utilizar el flag de gcc “-l” (L minúscula, sin comillas).

gcc main.c -L. -lalgebra
$ ./a.out
<a,b> = 10.00

Dado el flag “-lalgebra”, GCC comenzará a buscar un archivo denominado “libalgebra.a” (de aquí la imporancia en el nombre utilizado para la Biblioteca). El flag “-L” le indica a GCC donde se encuentra este archivo.

Espero que les sea útil.

Hoy descubrí un característica interesante sobre como funciona el polimorfismo en C++. Estaba obteniendo un mensaje de error del compilador (del linker, en realidad) que nunca había recibido antes.

(An english version of this post can be found here)

En mi código disponía de un fragmento similar al que presento a continuación, donde se define una clase abstracta “Base” y la clase “Derived” que hereda de esta mediante herencia pública. En C++ existen tres tipos distintos de herencia: Herencia Pública, Herencia Protegida y Herencia Privada. A los efectos de este artículo, lo que necesitan saber es que la Herencia Pública es similar a la que encontramos en otros lenguajes, como Java, C# u Objective-C.

#include <iostream>
using std::cout;
using std::endl;

class Base
{
	public:
		Base();
		virtual ~Base();
		virtual void printClassName() = 0; // =0 significa "abstract"
};

class Derived : public Base
{
	public:
		Derived();
		virtual ~Derived() { }
		virtual void printClassName();

};

Base::Base()
{
	this->printClassName();
}

Base::~Base()
{
}

Derived::Derived() : Base()
{
}

Derived::~Derived()
{
}

void Derived::printClassName()
{
	cout << "\"Derived\"" << endl;
}

int main()
{
	Derived* d = new Derived();
	delete d;
	return 0;
}

Ávidos conocedores de patrones de diseño probablemente hayan notado que este fragmento es una implementación del patrón Factory Method, donde tenemos una invocación a un método virtual, abstracto en la clase padre, que imprime el nombre de la clase que estamos instanciando.

El problema de este fragmento es que cuando invocamos el compilador, obtenemos el siguiente mensaje de error:

ale@syaoran factory]$ g++ main.cpp -Wall
Undefined symbols:
  "Base::printClassName()", referenced from:
      Base::Base()  in ccNxv98U.o
      Base::Base()  in ccNxv98U.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

Efectivamente, GCC nos advierte que no existe una implementación para el método abstracto “printClassName” y aborta!

¿Por qué sucede esto? El problema radica en la forma en que C++ maneja la herencia. Cuando se instancia un objeto cuya clase deriva de otra clase, primero se invoca el constructor de la clase base y luego se invoca el constructor de la clase derivada. Esto implica que el objeto derivado literalmente no existe hasta que se haya terminado de construir el objeto base “interior”.

En el caso de C++, esto implica que la tabla virtual (utilizada en tiempo de ejecución para aplicar polimorfismo) para el objeto derivado no es creada hasta que la construcción del objeto base se haya creado. Como nosotros estamos invocando un método abstracto dentro del constructor de la clase base, el GCC asume que se invocará la implementación del método en la clase base. Dado que éste no existe (ya que es abstracto), el linker tira un error.

Peor aún, si el método no fuese abstracto (pero sí virtual), el polimorfismo no funcionaría, invocando la implementación en la clase base y no en la clase derivada.

¿Cómo solucionamos este problema?

La solución, afortunadamente, es sencilla. Simplemente debemos tomar como regla general el siguiente enunciado:

“Nunca invocar métodos virtuales sobre objetos parcialmente construidos”.

Para reparar nuestro programa anterior, lo que haremos entonces, es remover la invocación al método virtual del constructor. Dónde ponerlo es una cuestión que, dependiendo de la aplicación, puede ser en un lugar u otro. Una opción que nos permite no cambiar demasiado el diseño es separar el proceso de construcción de un objeto en dos fases: una donde todos los constructores base se ejecutan y una donde se invoque un método especial init() desde el constructor la clase derivada que termine de inicializar el objeto. Esto nos permitirá trabajar una vez que toda la tabla de métodos virtual se encuentre creada.

Nuestro ejemplo reparado se vería de la siguiente forma:

#include <iostream>
using std::cout;
using std::endl;

class Base
{
	public:
		Base();
		virtual ~Base();
		virtual void init();
		virtual void printClassName() = 0; // =0 significa "abstract"
};

class Derived : public Base
{
	public:
		Derived();
		virtual ~Derived();
		virtual void printClassName();
};

Base::Base()
{
	//Invocación movida a init()
}

Base::~Base()
{
}

void Base::init()
{
	printClassName();
}

Derived::Derived() : Base()
{
}

Derived::~Derived()
{
}

void Derived::printClassName()
{
	cout << "\"Derived\"" << endl;
}

int main()
{
	Derived* d = new Derived();
	d->init();
	delete d;
	return 0;
}

Esta versión del código compila y linkea sin problemas. Al ejecutarla, felizmente obtenemos los siguientes resultados:

[ale@syaoran factory]$ ./a.out
"Derived"

Restaría probar como resuelven este problema otros lenguajes de programación orientados a objetos. Lo dejo como ejercicio para el lector

En mes de Abril se publicó una nueva edición del Índice Tiobe, el cual consiste en un listado de popularidad de lenguajes de programación.

La característica principal de este año consistió en que, tras 4 años, C volvió al puesto #1, dejando a Java en el segundo lugar.

De acuerdo con la comunidad detrás del índice, ésto se debió no a un aumento en la popularidad de C, sino a un descenso en la popularidad de Java. Este descenso se explica debido a la aparición de otros lenguajes capaz de hacer uso de la JVM, como es el caso de JavaFX.

Por su parte, C++ se mantiene firme en el puesto #3.

A la fecha, el top ten es el presentado a continuación:

1. C
2. Java
3. C++
4. PHP
5. (Visual) Basic
6. C#
7. Python
8. Perl
9. Delphi
10. JavaScript

Objective-C, cuyo crecimiento se explica debido a la explosión de popularidad del iPhone, ha logrado subir del puesto #42 al #11 en tan solo un año. Por su parte el lenguaje de programación de sistemas de Google, denominado “Go”, ha logrado hacerse con el puesto #15 en menos de un año de existencia.

Del sitio oficial:

El Índice Tiobe provee un indicador sobre la popularidad de los lenguajes de programación. El Índice se actualiza una vez al mes. Sus ratings se basan en el número de Ingenieros capacitados en todo el mundo, cursos y Terceros Vendedores.

Fuente: Tiobe Software.