Declaración de tipos

Extrañamemente se usan formas diferentes para declarar lo mismo. Porque declarar una variable o un nuevo tipo de dato debería ser consistente. Por ejemplo, para declarar una variable se usa <tipo de dato> <identificador>;. En cambio, para declarar un alias de un tipo de dato (no hay nuevos tipos) se usa using <identificador> = <tipo de dato>;. Y, ya para rematar, para declarar un delegate se usa delegate <valor devuelto> <identificador> (<parámetros>);.

¿No sería más sencillo y consistente tener una sintaxis común? Por ejemplo: <tipo de dato> <descripción> <identificador>;, con lo que la declaración quedaría:

// Variable:
int i;

// Tipo de dato:
typedef int MyInt;

// Usando 'using' (sin introducir ninguna palabra reservada adicional):
using int as MyInt;

// Delegate:
delegate void(int) MyDelegate;

Con esto la sintaxis siempre es consistente. Tenemos a la izquierda los tipos y a la derecha, siempre, el nombre tanto de la variable como del tipo nuevo como del delegate (que no deja de ser un tipo nuevo).

Nuevos tipos de datos

En C#, al igual que en C++, no se pueden declarar nuevos tipos de datos. Sí, en serio. Lo que estáis pensando ahora mismo es que con typedef sí se puede… pues no. En realidad es un alias del tipo básico. En C++, este código:

typedef int myint_t;
void overloaded_function(int value);
void overloaded_function(myint_t value);  // Error de compilación.

Daría error de compilación porque las dos funciones son iguales. myint_t no es un tipo de datos nuevo, sino un alias de int. En C# ocurre lo mismo, sólo que en lugar de declarar los nuevos tipos con typedef (que no tiene esa palabra reservada) se usa using:

using myint_t = int;

class Main {
  void overloaded_funcion(int value) {...}
  void overloaded_funcion(myint_t value) {...}  // Error de compilación.
}

También se puede hacer alguna triquiñuela, como hacer una clase MyInt que herede de System.Int32. Pero ya habría que implementar ciertas cosas para que funcionase.

Los métodos y su tipo de acceso

Es bastante enrevesado el uso de virtual, override y new para controlar el polimorfismo de las clases. Por ejemplo, en el código:

class A {
	public virtual void Who() { Console.WriteLine("A"); }
}

class B : A {
	public override void Who() { Console.WriteLine("B"); }
}

class C : B {
	public new virtual void Who() { Console.WriteLine("C"); }
}

class D : C {
	public override void Who() { Console.WriteLine("D"); }
}

C c = new D();
c.Who();	// Escribe "D"; lógico ¿no?

A a = new D();
a.Who();	// ¡Escribe "B"! ¿Dónde está la lógica de funciones virtuales aquí?

Es obligatorio que en todos los métodos que se podrán sobreescribir en clases derivadas se ponga virtual; que en todos los métodos que sobreescriben se ponga override; y que si un método oculta a otro se ponga new.

¿No sería más sencillo que todos los métodos fuesen virtuales por defecto (porque cuando haces clases, lo más probable es que las vayas a heredar)? ¿No sería más lógico que cuando declaras un método con el mismo nombre en la clase base, automáticamente se sobreescriba el de la base y, en caso de querer llamar al método de la base, uses super, base o similar?

Por cierto, decidme un caso real donde se use esta funcionalidad.

El problema de la clase base frágil

En este manual se menciona el problema de la clase base frágil, que habla de que en Java podría suceder esto, teniendo en principio estas clases:

class BaseClass {
	public void CleanUp() {
		System.out.println("BaseClass.CleanUp()");
	}
}

class DerivedClass extends BaseClass {
	public void Delete() {
		System.out.println("DerivedClass.Delete()");
	}
	public void CleanUp() {
		Delete();
	}
}

public class Test {
	public static void main(String[] args) {
		BaseClass k = new DerivedClass();
		k.CleanUp();
	}
}

La salida de este programa sería:

$ javac Test.java && java Test
DerivedClass.Delete();
$

Si luego implementamos el método Delete() en la clase base de esta forma:

class BaseClass {
	public void CleanUp() {
		System.out.println("BaseClass.CleanUp()");
	}
	public void Delete() {
		System.out.println("Delete all the world!");
	}
}

Según el manual, ¡podríamos borrar el mundo!

Esto sería un verdadero problema… si existiese. Pero es muy fácil comprobar que no se produce. La salida con la clase modificada es la misma que sin ella. Sólo usando super.Delete() se podría borrar el mundo.

Ámbito global o local

En C#, si una clase oculta un espacio de nombres, para acceder a dicho espacio introduce una nueva palabra que no está reservada, pero que hay que recordar: global. Por ejemplo:

class Main {

  public class System {}

  static void Main(string[] args) {
    System.Console.WriteLine("¡Hola mundo!");  // Error: la clase 'System' oculta
                                               // el espacio de nombres 'System'.
    global::System.Console.WriteLine("Esto sí funciona.");
  }
}

¿No sería más sencillo, en lugar de introducir otro identificador nuevo, usar sólo el operador ::, como hace C++ o, incluso, usar el operador .?

Comportamientos extraños de las variables

Resulta que si declaras una variable de tipo delegate, esta se comporta como una lista de delegates que se llaman todos seguidos:

class Test {
	void Notify1(string text) {
		System.Console.WriteLine("Hello " + text);
	}
	void Notfiy2(string text) {
		System.Console.WriteLine("Goodbye " + text);
	}
}

Test test = new Test();

delegate void Notifier(string text);

Notifier notifier;
notifier = new Notifier(test.Notify1);
notifier += new Notifier(test.Notify2);

notifier("Manolito");

// La salida será:
// Hello Manolito
// Goodbye Manolito

¿Nos aclaramos? ¿Notifier es una variable o es una lista de variables? Y si todos los delegates asignados devuelven algún valor, sólo se devuelve el último ejecutado. ¿Y el resto?

Recorriendo listas

C# añade el foreach, que no es más que lo que se conoce como syntactic sugar para el bucle for de toda la vida evitando que el programador use variables índice:

string[] stringArray = new string[] { /* Inicialización */ };

foreach(var s in stringArray) {
  System.Console.WriteLn(s);
}

Pero no estoy criticando ese syntactic sugar, todo lo contrario, eso me parece muy bien. Cuanto menos código se escriba y haga más cosas, mejor.

Lo que ya no me parece tan bien es que en ese bucle foreach sólo se tenga acceso a los valores de la lista a recorrer y no se tenga acceso al índice de dicha lista. Sí, simplemente a la famosa i que se omite para que el programador escriba menos código.

Y por culpa de esto, en caso de necesitarla, pues tienes que declararla fuera e incrementarla manualmente. Vamos, con en un bucle for.

Anidamiento

No se permiten métodos anidados, es decir, declaración e implementación de métodos dentro de otros métodos. Sí, venga, vale, se puede “solucionar” mediante el uso de delegates, pero eso no es permitir métodos anidados, eso es una chapuza.

Y además, ya para rematar, tampoco se permite declarar estructuras ni clases dentro de métodos. Como está orientado a objetos, pues toda declaración adicional tiene que ir dentro de la clase.

Actualización 2011-12-05: C y C++ tampoco permiten métodos anidados como me indican en un comentario. Esto lo puse porque yo los he usado para resolver algún problema, sólo que no recuerdo ni el lenguaje ni el proyecto en el que lo hice. ¿Pascal quizás?

Atributos

Los atributos del lenguaje también son otra cosa que está muy bien dentro de un lenguaje. Permiten extender la funcionalidad del compilador, por ejemplo, para hacer compilación condicional, controlar entre diferentes versiones o arquitecturas, marcar elementos como obsoletos… pero, me pregunto, ¿por qué la sintaxis no es coherente con el resto del lenguaje y hay que añadir triquiñuelas del estilo [Conditional("Debug")] al código?

Conclusión

Después de despotricar un poco toca una pequeña conclusión:

Si Microsoft tuvo la oportunidad de crear un nuevo lenguaje de programación desde cero, para ellos solos, sin que nadie se pueda meter, sin que nadie le diera lecciones, con la posibilidad de innovar, de mejorar lo que había hasta el momento ¿por qué lo ha hecho tan retorcido e incoherente? Porque sí, en serio, es retorcido. Hasta C++ —que mira que a Bjarne Stroustrup se le fue la olla cuando lo diseñó— es más consistente y coherente que C#. C# parece un batiburrilo de Java, C++ y alguna funcionalidad adicional como los delegates que más que ser un lenguaje nuevo es lo mismo de siempre con otro nombre. Y propietario, claro.

Y, bueno, de la compilación a código intermedio en lugar de a código máquina directamente ya no hablamos. Eso es una decisión que han tomado pero que tampoco es que importe demasiado. Recordemos que esta generación de código es una de las fases de compilación que se puede cambiar sin afectar a la sintaxis.

Concluyendo, a mi, personalmente, no me convence en absoluto. Pero claro, si quieres hacer un proyecto decente para sistemas Windows, no queda otra que hacerlo en C# o pelearte con los punteros en C++.

O usar Pascal .

P.D.: Yo, en realidad, soy más del lenguaje de programación D.

La forma sencilla e intuitiva

template <typename T>
char*
ValueToBits(T value) {
	int length = sizeof(T)*8;
	char* result = new char[length];
	result[length] = '\0';
	for(int i = 0; i < length; i++) {
		result[length-1-i] = (value & (1 << i) ? '1' : '0');
	}
	return result;
}

Este algoritmo es fácilmente adaptable a C estándar. Basta con quitar la plantilla, sobrecargar esta función con más versiones, una por cada tipo de dato que se quiera convertir, y usar malloc() en lugar de new. Y, por supuesto, no hay que olvidarse de liberar la memoria del valor devuelto, o bien con delete[] si usas new, o bien con free() si usas malloc().

Usando std::strings

Este algoritmo es similar al anterior pero usando std::strings, con lo que evitamos el uso de char* y la reserva manual de memoria.

#include <string>

using std::string;

template <typename T>
const string
ValueToBits(T value) {
	string result;
	for(int i = 0; i < sizeof(T)*8; i++) {
		result = (value & (1 << i) ? "1" : "0") + result;
	}
	return result;
}

La forma elegante

Y ya que estamos en C++, ¿por qué no usar toda la potencia que nos proporciona la STL?

#include <bitset>

using std::bitset;

template <typename T>
const string
ValueToBits(T value) {
	return bitset<sizeof(T)*8>(value).to_string();
}

No me digáis que esta forma no es muy elegante .

El uso de circunloquios para reflejar que se refiere a “ellos y ellas” solo tiene sentido si tu mente es tan simple como para pensar que podría estar refiriéndome a “ellos” y no a “ellas”.

En un comentario de Menéame sobre la noticia de que por fin se usa el sentido común para el género en el lenguaje.

Por ejemplo, aquí tenemos una prueba de concepto para tener la misma funcionalidad que el operador << de C++ pero usando llamadas encadenas. Y hace (casi) lo mismo: puede enviar a la salida estándar cualquier tipo de variable, incluyendo cadenas, números enteros, números reales y booleanos, sólo que con un formato de llamada diferente.

La implementación de la clase base, pudiendo extenderla lo que se quiera, es la siguiente:

Y un ejemplo de funcionamiento sería:

Siendo la salida:

$ make && ./test
Llamadas encadenadas: enteros: 42; reales: 25.4; y booleanos: false.
$

No tiene la misma funcionalidad que el operador << porque, entre otras cosas, si se quiere añadir otro elemento imprimible habría que derivar la clase, mientras que con el operador << bastaría con sobrecargarlo. Pero no me digáis que no es elegante ¿eh? .

En el inicio de la carrera, uno de los lenguajes que usábamos era Pascal¹ porque era un lenguaje muy bueno para aprender por su sintaxis y no tan complicado como el C con los punteros (aunque también los tiene).

Después, con el ansia de hacer cosas más «profesionales» descubrí Delphi allá por la versión 3, para tener ya aplicaciones con interfaz gráfica escritas en Pascal avanzado (orientado a objetos y demás).

Es en esta época que mezcla el estudio de la carrera con la programación en Delphi en la que soy más productivo: hice infinidad de aplicaciones, principalmente para aprender a programar (por mi cuenta, todo hay que decirlo) aunque alguna sí que se salvó y usaba uso habitualmente.

Luego, con esto de la salida del estudio para integrarse en el mundo laboral, dejé de lado el Delphi para centrarme en… bueno, en lo que tocara en ese momento.

Pero ahora me he encontrado con que tengo que volver a hacer una aplicación, con interfaz gráfica (un editor de JSON principalmente aunque algo especial) y tiene que funcionar tanto en Windows como en Linux. En su momento probé Java pero necesitaba dos librerías que había que distribuir con el *.jar, así que le volví a dar una oportunidad al Pascal, aunque esta vez de la mano de Lazarus y FreePascal.

¿Y por qué FreePascal/Lazarus? Pues porque me ha sorprendido muy gratamente que el código fuente se compila y ejecuta sin ningún cambio en Windows y Linux (obviamente son ejecutables distintos pero un sólo código fuente). No hay que preocuparse en ningún momento de directivas de compilación, de hacer diferente código para diferentes sistemas operativos y basta con distribuir un sólo ejecutable.

Además, la interfaz gráfica es totalmente coherente con la interfaz general del sistema sin ningún cambio en el código. Si estás en Linux tienes los temas de Linux y si estás en Windows tienes los temas de Windows. Incluso con los efectos de Windows 7.

Cierto es que hay lenguajes más “modernos” como Python, pero digamos que Python y yo no somos muy amigos. Y pongo “modernos” entre comillas porque en realidad no importa la modernidad del lenguaje: C es de 1972, C++ de 1980 y Cobol (el lenguaje que usan muchísimos sistemas bancarios) es de 1960.

En definitiva, si queréis desarrollar rápido una aplicación y habéis hecho vuestros pinitos en Pascal/Delphi hace sus años, Lazarus es una buena opción. Eso sí, no le pidáis peras al olmo porque esto es para lo que es: desarrollo rápido pero casi sin planificación y con un código un poco spaghetti (es lo que tiene el desarrollo dirigido a eventos). Y tened en cuenta también que esta experiencia no os servirá para mucho más. Aún así a mi me está resolviendo la papeleta de una forma muy… elegante .

Nota: Considero que Pascal es un lenguaje de programación excelente para aprender a programar porque abstrae mucho más que C y similares de los entresijos de la arquitectura del ordenador centrando la atención en los algoritmos y en las estructuras de datos. Y lo mismo pienso de la programación orientada a objetos: no se debería ver hasta tener una buena base de programación estructura y, ni mucho menos, iniciarse en la programación usando POO. Y parece que esto último no soy el único que lo piensa.

Para ponernos en antecedentes, digamos que tenemos una aplicación multihilo escrita en C++ en Linux. Cuando en uno de los hilos se produce una excepción, esta debe ser atrapada (try { ... } catch(...) { ... }) dentro del propio hilo. En caso de que no se haga así, la excepción se propaga al hilo principal (main()) sin posibilidad de atraparla, con lo que la aplicación finaliza.

Para resumir este punto: las excepciones no se propagan entre diferentes hilos de ejecución por lo que hay que atraparlas y procesarlas dentro del propio hilo.

Pero ¿qué pasa cuando queremos que una excepción sí se propague a otros hilos? Es decir, que un error que se produce en un hilo se notifique a otro hilo para que tome medidas. Por ejemplo, tenemos un hilo que gestiona las comunicaciones y otro que gestiona la interfaz. Cuando se produce un error de comunicación es la interfaz la que tiene que notificar al usuario de dicho error.

Soluciones existen varias. Una de ellas es enviar un mensaje con la excepción que se produce al hilo que la procesa aunque hay que tener en cuenta que debe haber una arquitectura de paso de mensajes entre hilos previa.

Por ejemplo, en pseudocódigo, el hilo de comunicaciones:

Y ahora el hilo de proceso de las notificaciones en la interfaz:

El problema del proceso de procesado de excepciones en la interfaz es que al relanzar la excepción que se recibe como parámetro (throw e;) esta no es la excepción recibida en el hilo de comunicaciones, es decir, no hay polimorfismo por lo que siempre se procesa como una excepción general en lugar de la correspondiente.

La opción de usar typeid(e).name() en la excepción para procesar su tipo no es viable porque es demasiado costosa (el operador typeid es bastante costoso) y porque el nombre de la excepción no es estándar, esto es, en GNU C++ (g++) el nombre está “retorcido”, mangled en inglés.

La opción recomendable es añadir a la excepción base de tu aplicación, teniendo en cuenta que para tu aplicación has desarrollado una jerarquía de excepciones acorde con su funcionalidad, un método virtual que implementen las excepciones derivadas donde, simplemente, se lancen a sí mismas.

Un código de ejemplo sería el siguiente:

Con esta forma de declarar las excepciones, el código de gestión de las notificaciones de error en la interfaz quedaría:

Con lo que funcionaría sin ningún problema ya que la excepción se lanza de forma polimórfica al usar un método virtual en la clase base que implementan todas las clases derivadas.

Para hacer una prueba se puede descargar un archivo con un programa de ejemplo (1,4 KB). Para compilarlo basta con ejecutar el comando g++ -o test exception-test.cpp.

Y por ir un poco más allá, se podría pensar que para implementar todas las excepciones que usa una aplicación habría que escribir bastante código, además, la mayoría sería repetido; lo único que cambiaría sería el nombre de la excepción y del constructor, el resto es todo igual.

Bueno, pues para eso están las macros de C: se puede crear una macro a la que se le pase como parámetro el nombre de tu nueva excepción y que ella genere todo el código restante. Pero no olvidéis que las macros son malignas en 4 formas diferentes.

Un ejemplo de una función en C con argumentos variables sería el siguiente:

Para declarar una función que tenga un número indefinido de argumentos es necesario incluir los puntos suspensivos (…) como argumento, pero al menos debe tener uno que no sea indefinido, esto es, primero un argumento y, posteriormente, los puntos suspensivos. Esto es así porque en la función va_start() hay que pasarle, como segundo argumento, el nombre del último argumento conocido de la función. Si no tuviese al menos un argumento conocido no se podría pasar este argumento a la función va_start().

También se pueden crear métodos (funciones dentro de clases) que tengan la lista de argumentos variable, incluidos los constructores de las clases, de la forma:

Y dirán ustedes ¿y aquí por qué no se pone al menos un argumento como nos acabas de indicar?

Y yo voy a responder con otra pregunta: ¿qué es lo que te enseñan el primer día de curso de programación orientada a objetos sobre los métodos de una clase? Que los métodos no estáticos de una clase tienen un argumento implícito que es un puntero a la instancia de dicha clase. El famoso puntero this en lenguajes como C++, Java, D y alguno que otro más.

Y como este argumento es el primero del método, se puede pasar sin problemas como segundo argumento de la función va_start() para indicar que es el último definido de la lista. La implementación sería, más o menos, así:

Esto de los argumentos indefinidos en C y C++ es una de las chapuzas que hay para tener esta funcionalidad ya que, en su mayoría, se hace con macros (aunque están implementadas de forma interna al compilador).

Hasta que no tengamos el estándar C++0x (el nuevo estándar de C++ que supongo que ya quedará poco para que salga definitivamente) no tendremos esta característica incluida en el lenguaje. Incluso se ha ampliado a parámetros variables en las plantillas (variadic templates), con lo que podremos tener tuplas de n elementos de distinto tipo. Pero, de momento, nos conformaremos .

Yo no soy víctima de la LOGSE. Tengo 48 años y he tenido la suerte de estudiar bajo unos planes educativos buenos, que primaban el esfuerzo y la formación de los alumnos por encima de las estadísticas de aprobados y de la propaganda política.

En párvulos (así se llamaba entonces lo que hoy es “educación infantil”) empecé a estudiar con una cartilla que todavía recuerdo perfectamente: la A de “araña”, la E de “elefante”, la I de “iglesia” la O de “ojo” y la U de “uña”.

Luego, cuando eras un poco más mayor, llegaba “El Parvulito”, un librito con poco más de 100 páginas y un montón de lecturas, no como ahora, que pagas por tres tomos llenos de dibujos que apenas traen texto. Eso sí, en “El Parvulito”, no había que colorear ninguna página, que para eso teníamos cuadernos.

En 8º de EGB, si en un examen tenías una falta de ortografía del tipo de “b en vez de v” o cinco faltas de acentos, te suspendían.

En BUP, aunque yo era de Ciencias, estudié Historia de España (en 1º), Latín y Literatura (en 2º) y Filosofía (en 3º y en COU).

Leí El Quijote y el Lazarillo de Tormes; leí las “Coplas a la Muerte de su Padre” de Jorge Manrique, a Garcilaso, a Góngora, a Lope de Vega o a Espronceda…

Pero, sobre todo, aprendí a hablar y a escribir con corrección. Aprendí a amar nuestra lengua, nuestra historia y nuestra cultura.

Aprendí que se dice “Presidente” y no Presidenta, aunque sea una mujer la que desempeñe el cargo.

Y… vamos con la Gramática.

En castellano existen los participios activos como derivado de los tiempos verbales.

El participio activo del verbo atacar es “atacante”; el de salir es “saliente”; el de cantar es “cantante” y el de existir, “existente”. ¿Cuál es el del verbo ser? Es “el ente”, que significa “el que tiene entidad”, en definitiva “el que es”. Por ello, cuando queremos nombrar a la persona que denota capacidad de ejercer la acción que expresa el verbo, se añade a este la terminación “-nte”.

Así, al que preside, se le llama “presidente” y nunca “presidenta”, independientemente del género (masculino o femenino) del que realiza la acción.

De manera análoga, se dice “capilla ardiente”, no “ardienta”; se dice “estudiante”, no “estudianta”; se dice “independiente” y no “independienta”; “paciente”, no “pacienta”; “dirigente”, no dirigenta”; “residente”, o “residenta”.

Y ahora, la pregunta del millón: nuestros políticos y muchos periodistas (hombres y mujeres, que los hombres que ejercen el periodismo no son “periodistos”) ¿hacen mal uso de la lengua por motivos ideológicos o por ignorancia de la Gramática de la Lengua Española? Creo que por las dos razones.

Es más, creo que la ignorancia les lleva a aplicar patrones ideológicos y la misma aplicación automática de esos patrones ideológicos los hace más ignorantes (a ellos y a sus seguidores).

Os propongo que paséis el mensaje a vuestros amigos y conocidos, en la esperanza de que llegue finalmente a esos ignorantes semovientes (no “ignorantas semovientas”, aunque ocupen carteras ministeriales).

Lamento haber aguado la fiesta a un grupo de hombres que se habían asociado en defensa del género y que habían firmado un manifiesto.

Algunos de los firmantes eran: el dentisto, el poeto, el sindicalisto, el pediatro, el pianisto, el golfisto, el arreglisto, el funambulisto, el proyectisto, el turisto, el contratisto, el paisajisto, el taxisto, el artisto, el periodisto, el violinisto, el taxidermisto, el telefonisto, el masajisto, el gasisto, el trompetisto, el violinisto, el maquinisto, el electricisto, el oculisto, el policío del esquino y, sobre todo, ¡el machisto!

Carta de una profesora de música de un instituto que me ha llegado por correo. Seguro que está en mil sitios, pero esto siempre es bueno recordarlo.

Para ponernos en antecedentes, tenemos una clase Thread en C++ que representa hilos de ejecución. Esta clase tiene un método execute() que es el que realmente ejecuta el hilo. De esta se puede heredar para implementar dicho método y que este se ejecute en un hilo independiente. La clase Thread cuenta con métodos protegidos (protected) para que sólo los usen las clases derivadas.

Pero, además de derivar la clase Thread, esta clase tiene una clase anidada llamada Thread::Worker que también se puede derivar con la ventaja de que se pueden pasar muchas instancias de Thread::Worker a una sola instancia de la clase Thread para que las ejecute.

El problema surge cuando desde la clase Thread::Worker, al igual que desde las subclases de Thread, se desea acceder a los métodos protegidos (que, en teoría, son sólo para ayudar en la funcionalidad de las clases derivadas). Inicialmente esto no es posible ya que no se puede acceder a métodos protegidos de una clase si no es desde la propia clase o desde clases derivadas, no importa si son clases anidadas, a efectos de protección, son como clases externas.

Con algunas omisiones de código, la implementación de las clases es la siguiente:

La funcionalidad deseada es que la clase Thread::Worker se comporte como la clase Thread cuando se hacen clases derivadas de ella, para poder usar la funcionalidad de gestión de la clase Thread desde la clase Thread::Worker (las funciones protegidas).

Pero al compilador no le gusta que se llamen funciones protegidas desde clases externas aunque sean anidadas.

La solución pasa por crear un puntero a método en la clase anidada que sea asignado a la función que hay que ejecutar. Cuando la instancia de la clase Thread::Worker es añadida a la instancia de la clase Thread, esta última asigna las direcciones de memoria de sus métodos a las variables internas de la clase Thread::Worker, con lo que una llamada mediante dichos punteros funcionará sin problemas y ejecutará el método protegido de la clase Thread desde la clase externa Thread::Worker.

La implementación sería, más o menos de la siguiente forma:

Con esto se consigue que la clase Thread::Worker se comporte, a efectos de derivación de clases, como si se derivase de la clase Thread. Hay que tener en cuenta que las clases derivadas de la clase Thread::Worker siempre se tienen que añadir a una instancia de la clase Thread para todo funcione correctamente.

Como es bastante difícil interpretar código fuente desde esta lectura, he preparado una pequeña aplicación en C++ para mostrar el funcionamiento de este tipo de solución.

Espero que esto sirva para alguien a parte de mi. Y si lo encontráis por algún otro sitio me lo comentáis, porque como he dicho al principio, seguro que no soy el primero en hacerlo.

chacha, chachi, chacho, cheche, Chechu, chicha, chiche, chichi, chicho, chocha, chocho, chuche, chucha y chucho.

Al final han salido 14, aunque algunas no están en el diccionario de la RAE, pero seguro que a nadie se le escapa el significado. Además, tampoco he contado las que tienen más vocales o consonantes entre estas. Ahora sólo se me ocurre Chencho (el hijo pequeño de La gran familia). ¿Alguna más?

Y hasta aquí ha llegado la entrada chorra del día .

Pero la cuestión que quiero comentar es que hayan dado un buen paso hacia delante (que lo han hecho, por cierto), sino la calidad del código en sí (suelo echar un vistazo al código fuente de los proyectos libres, simplemente por ver como están hechos).

Independientemente de si está bien programado o no, de si han diseñado bien la arquitectura o no, la calidad del código es impresionante: está limpio, ordenado, bien indentado, con espacios entre operadores, con las llaves correctamente colocadas,… vamos, como a mi me gusta.

Habiendo visto más código fuente, sobre todo de proyectos GNU, este es uno en los que mejor está escrito el código. De hecho, se parece mucho al código de las aplicaciones que se escribían para el BeOS (que también eran en C++). Lo único que hecho en falta es que el tipo de dato que retorna una función no esté en una línea distinta (la anterior) a la del nombre y parámetros de la función, algo que se estilaba mucho en BeOS.

Sin duda es una buena noticia el hecho de que se liberase el código, pero también es buena noticia que haya tanta calidad en el mismo, ya que con el peso que tiene Google ahora mismo como ejemplo de hacer las cosas (no se si para bien o para mal, pero tiene peso) queda claro que habrá muchos seguidores que hagamos código similar con lo que nuestros proyectos ganarán en legibilidad y mantenibilidad.

Este documento muestra el estilo de programación que yo sigo a la hora de realizar mis proyectos, tanto personales como laborales.

Esta guía es sólo una recomendación a seguir, nadie está obligado a hacerlo, pero siguiendo estas recomendaciones (u otras recomendaciones pero siendo siempre coherente) se consigue que el código fuente de nuestros proyectos sean más legibles y, sobre todo, más mantenibles.

Si te gusta que tu código esté bien escrito, échale un vistazo y comenta tu punto de vista; aunque si has llegado hasta aquí seguro que también tienes la tuya propia y tu código ya sale “bien visto” .

Página descubierta desde Kabytes donde se implementa el famoso “Hola mundo!” en 421 lenguajes de programación diferentes.

Los más divertidos son los llamados lenguajes de programación esotéricos como el Piet, el Brainfuck, el Ook! o el Whitespace. Pero el resto también tienen su gracia, sobre todo los ensambladores de varias máquinas.

Además de esto, también tenemos el programa “99 botellas de cerveza” (“99 bottles of beer” en inglés, que es algo así como “Un elefante se balanceaba…” pero restando. Aquí sabemos que terminaremos algún día) implementado en 1259 lenguajes de programación diferentes (no sabía que había tantos).

Me ha llamado la atención la implementación en Delphi. Tan sencillo y amigable él, y aquí lo flipé.

Y para terminar de rayar la cabeza, recordemos el ininteligible “Hola mundo!” en C ofuscado.

P.D.: Yo que quería hacer mi propio lenguaje de programación al que llamaría D++ (porque D ya está cogido) y resulta que D++ también está cogido. ¡Leches!

Existen dos tipos de lenguajes de programación: por un lado, aquellos de los que la gente se queja todo el rato; por otro, los que nadie utiliza.

Bjarne Stroustrup, científico de la computación y desarrollador del lenguaje de programación C++.

La actual tendencia al desdoblamiento indiscriminado del sustantivo en su forma masculina y femenina va contra del principio de economía del lenguaje y se funda en razones extralingüísticas. Por tanto, deben evitarse estas repeticiones, que generan dificultades sintácticas y de concordancia, y complican innecesariamente la redacción y lectura de los textos.

Lo dice la RAE (negritas mías) y yo lo vi primero en DesEquiLIBROS.

Y como odio que se use la arroba (@) para simbolizar el género neutro. Llamadme Talibán del lenguaje (que no lo soy, que también cometo mis faltas) pero hay que cosas con las que no puedo.