Debo admitir que cuando empecé a trabajar como programador, tampoco sabía lo que es un Dialecto de Lenguaje de Programación ni que un lenguaje de programación evoluciona con el tiempo y es revisado continuamente por expertos para mejorarlo día a día.

Después de investigar y recoger información, puedo intentar responder a la pregunta:

¿Qué es C++11?

Es la cuarta revisión del Lenguaje de Programación C++, no se llama C++4 porque las revisiones no se numeran por el orden de revisión si no por el año en que los chicos de la Organización Internacional para la Estandarización (ISO) dan el visto bueno a la revisión del lenguaje (también conocida como Dialecto del Lenguaje de Programación).

C++ ya tiene una larga historia; ya puestos a hablar de las revisiones  y cambios de C++ a lo largo del tiempo, tal vez podríamos pensar en profundizar el tema y preguntarnos

¿Cómo empezó todo?.

Los lenguajes de programación han ido evolucionando con los ordenadores, al fin y al cabo son la herramienta que nos permite trabajar con ellos; así que la historia nos remonta a la década de los 60, cuando los ordenadores estaban dando sus primeros pasos y con ellos los primeros pasos de los lenguajes de programación.

En esa década nos encontramos FORTRAN como lenguaje diseñado específicamente para el cálculo numérico, computación científica… y nada más. Al ser un lenguaje con un único propósito era necesario tener alguna alternativa más genérica. Con ese objetivo se diseñó ALGOL que por desgracia tampoco era práctico para crear aplicaciones comerciales y no llegó a tener mucho éxito, pero sirvió de inspiración para otros lenguajes procedurales posteriores como CPL, C y el propio C++.

En 1963 aparece el siguiente intento de crear un lenguaje de propósito general: el lenguaje CPL. Fue diseñado para cubrir las necesidades a las que ALGOL y FORTRAN no llegaban; pero seguía siendo demasiado específico a la par que era difícil de aprender, enseñar e implementar. Pero la idea era buena, así que en los siguientes años se dedicaron muchos esfuerzos a simplificarlo para hacer de CPL un lenguaje más práctico.

En 1967, Martin Richards desarrolló el lenguaje BCPL, este lenguaje era una simplificación del lenguaje CPL sin perder sus características más importantes; añadió también la compilación en dos pasos que se popularizó en compiladores posteriores: el código se compilaba en código máquina para una máquina virtual que después era usado para compilar en el tipo de sistema deseado. Pero aún con las simplificaciones, mejoras y novedades seguía siendo demasiado abstracto y complicado.

En 1970, Ken Thompson, durante el desarrollo de UNIX®, creó el Lenguaje B. Se trataba de una simplificación de BCPL para hacerlo caber en equipos de la época. Inicialmente se desarrolló para un equipo y sistema operativo concretos (DEC PDP-7 bajo UNIX®) y sólo tenía un tipo de datos (valor entero del mismo tamaño que la palabra de procesador). Su mayor aporte fue la invención de los punteros y ser el precursor del Lenguaje C.

Durante 1971, Dennis Ritchie siguió trabajando sobre el Lenguaje B. Se le añadieron nuevos tipos de datos, y mejoras en los array y punteros a datos. Esta colección de cambios se conoció durante un tiempo como “Nuevo B”; pero los cambios realizados eran tan importantes que no tenía sentido seguir llamándolo B, por lo que se le buscó un nuevo nombre, y así nació el Lenguaje C.

En los siguientes años, la flexibilidad, velocidad y portabilidad de C contribuyeron a una rápida expansión del lenguaje, y en 1979 ya era un lenguaje ampliamente usado. Por ello, Bjarne Stroustrup lo tomó como base para añadirle una serie de mejoras. Quería mejorar C usando características de programación orientada a objetos inspiradas en Simula. De otros lenguajes veteranos como ADA, CLU y ML obtuvo ideas como clases, herencia, tipado fuerte, funciones inline y argumentos por defecto.

Esta mejora de C sobre la que trabajaba Stroustrup era conocida como “Nuevo C” y durante la década de los 80, se fue refinando hasta transformarse en un lenguaje con identidad propia. En el proceso, perdió compatibilidad en algunos aspectos concretos con su predecesor, pero gracias a ello pudo desarrollar sus más importantes características. Al medida que el lenguaje “Nuevo C” se encaminaba hacia la programación orientada a objetos se le fue conociendo como “C con clases” hasta que, en 1983 se le cambió el nombre a “C++” de manera oficial.

El nuevo nombre se le atribuye a Rick Mascitti, que lo usó por primera vez en diciembre de 1983 y según sus propias palabras se trata de un juego de palabras que combina el operador de incremento del Lenguaje C con la costumbre de añadir un “+” para etiquietar la versión superior de un programa; de esta manera se refleja que C++ es un paso adelante con respecto al Lenguaje C. Según el creador del lenguaje, Bjarne Stroustrup, considera dicho nombre como “una muestra de la naturaleza evolutiva de los cambios sobre C”.

El 14 de Octubre de 1985 se lanzó la primera implementación comercial de C++, la versión 2.0 de C++ vio la luz en 1989 y el año siguiente se publica “The Annotated C++ Reference Manual“, el cual acaba siendo la base del futuro estándar.

Para 1991 C++ había crecido ¡y mucho! se le habían añadido nuevas e interesantes funcionalidades como herencia múltiple, clases abstractas, funciones miembro estáticas, funciones miembro constantes y miembros protegidos. En los años siguientes, se siguió ampliando el lenguaje con plantillas, control de excepciones, espacios de nombres, nuevos transformadores de tipos y el tipo booleano.

Y en la década de los 90 empezamos la recta final de la historia de C++. En esta década el lenguaje fue considerado estándar y en 1998 ISO lo ratificó dando lugar al primer dialecto de C++ conocido como C++98.

A partir de la primera revisión del lenguaje, se van sucediendo periódicamente diferentes revisiones, en 2003 se aprueba la segunda revisión conocida como C++03.

Y en la década de los 2000, entran en juego los Technical Report, que son documentos mantenidos por los mayores eruditos del C++ en que se recopilan propuestas a incluir en la librería estándar. Los Technical Report no son parte del estándar de C++, pero muchas de sus propuestas acaban formando parte del mismo.

El primer Technical Report, publicado en 2005, propone múltiples añadidos al dialecto C++03, y en 2007 se publica un nuevo estándar que fue conocido como C++TR1 por incluir en el estándar parte de dicho documento.

Y finalmente llegamos a la cuarta revisión de C++, aprovada el 12 de Agosto de 2011. Esta nueva revisión ha sido muy esperada, a la vez que lenta y llena de retrasos. Como no se sabía exactamente cuándo iba a ser aprovada (se esperaba para 2008 o 2009), ha sido conocida durante mucho tiempo como C++0x, la idea era substituir la “x” por el dígito adecuado pero una vez llegados a 2010 se empezó a bromear afirmando que era una marca Hexadecimal. El apodo de C++0x se ha popularizado mucho, por lo que mucha de la información de C++11 puede ser encontrada bajo la etiqueta de C++0x.

Hemos llegado hasta C++11 pero ¿Qué será lo siguiente?

Parte de los retrasos sufridos por C++11 se deben a la gran cantidad de cambios que se querían hacer sobre el lenguaje y la librería estándar; cada cambio debe ser evaluado, discutido y aprovado por el comité de estándares y eso lleva su tiempo.

Así que algunos cambios propuestos quedaron en el tintero, en parte para no engordar más el Dialecto C++11 y en parte para no retrasar más su lanzamiento.

Los cambios que no llegaron a entrar en C++11 están siendo recopilados en un nuevo informe técnico, el “Technical Report 2″, que está previsto que se publique tras la aprobación de C++11 y muy posiblemente sea la base para un nuevo estándar de C++ en el futuro.

Por lo que, lo próximo que debemos esperar en cuanto a C++ es la publicación del “Technical Report 2″ y una nueva ronda de reuniones del comité de estándares pero, mientras que lo primero será en breve, para lo segundo deberemos esperar unos años aún.

Entre las facilidades para hacer más seguro el código, encontramos varias enfocadas a cualificar adecuadamente los datos; esto es, evitar que un dato sea interpretado con un tipo cuando se espera otro o bien, que un tipo se convierta a otro sin control.

Una de estas novedades es el  nuevo tipo de  Enumerado C++11, el Enumerado-Clase (llamado así porque tiene características de Enumerado y de Clase).

Estos nuevos enumerados amplían la funcionalidad del enumerado tradicional permitiendo cualificar explícitamente sus miembros; no substituyen al enumerado tradicional si no que conviven con él, por lo que cualquier código previo a C++11 que haga uso de enumerados seguirá siendo válido.

Podemos ver un ejemplo de su uso y utilidad, al analizar código común hoy en día; por ejemplo, es común intentar forzar el rango de valores de un enumerado mediante un miembro de forzado:

enum E_MY_FAVOURITE_FRUITS
{
    E_APPLE        = 0x01,
    E_WATERMELON   = 0x02,
    E_COCONUT      = 0x04,
    E_STRAWBERRY   = 0x08,
    E_CHERRY       = 0x10,
    E_PINEAPPLE    = 0x20,
    E_BANANA       = 0x40,
    E_MANGO        = 0x80,
    E_MY_FAVOURITE_FRUITS_FORCE8 = 0xFF // <-- Forzamos a 8 bits.
};

La idea es que el último miembro (E_MY_FAVOURITE_FRUITS_FORCE_8_) indica el ancho de bits del enumerado (dato necesario para rutinas de serialización y deserialización, por ejemplo); pero el anterior estándar de C++ (conocido como C++03) no ofrece ningún control del ancho de bits de un enumerado ni ninguna manera fiable de garantizar que un valor de enumerado tenga un ancho de bits determinado.

Es más, la decisión del ancho de los datos de un enumerado ¡no es del programador! es algo que decidirá el compilador por nosotros, tal y como nos indica el estándar:

“La expresión que define el valor de una constante de enumerado debe ser una expresión constante cuyo valor sea representable por int”.

“Todo enumerado debe ser compatible con char o cualquier entero con o sin signo. La elección del tipo es dependiente de implementación, pero debe ser capaz de representar el valor de todos los miembros del enumerado”.

Por lo tanto, crear un miembro de forzado en el enumerado, además de que no garantiza que el tipo sea el esperado, requiere código extra (por lo que es incómodo de escribir y mantener) y dado que el compilador decide el ancho de bits del dato, si accidentalmente añadimos un nuevo miembro al enumerado que supere el valor de forzado ¡el compilador amplía el ancho de bits sin dar ningún aviso!

enum E_MY_FAVOURITE_FRUITS
{
    E_APPLE        = 0x01,
    E_WATERMELON   = 0x02,
    E_COCONUT      = 0x04,
    E_STRAWBERRY   = 0x08,
    E_CHERRY       = 0x10,
    E_PINEAPPLE    = 0x20,
    E_BANANA       = 0x40,
    E_MANGO        = 0x80,
    E_DEVIL_FRUIT  = 0x100, // Nueva fruta, con valor mayor a 8 bits
    E_MY_FAVOURITE_FRUITS_FORCE8 = 0xFF // <-- Forzamos a 8 bits.
};

Nuestro compilador, silenciosa y automáticamente cambiará el ancho de bits del enumerado porque  su nuevo miembro (E_DEVIL_FRUIT) ocupa 9 bits, así que deberá ser almacenado en un short o int ¡si es que no estaba ya almacenado en un entero!

Mal asunto, si usábamos el ancho de bits del enumerado para algún cálculo (por ejemplo, para rutinas de serialización y deserialización) a partir del la inclusión de E_DEVIL_FRUIT, ¡todos esos cálculos podrían ser erróneos!

Pero este no es el único comportamiento peculiar de los enumerados tradicionales, excepcionalmente y, a diferencia de las Clases y Estructuras, exportan sus nombres al espacio de nombres inmediatamente superior; si por ejemplo usamos el enumerado de frutas en un espacio de nombres:

namespace Fruits
{
enum E_MY_FAVOURITE_FRUITS
{
    E_APPLE        = 0x01,
    E_WATERMELON   = 0x02,
    E_COCONUT      = 0x04,
    E_STRAWBERRY   = 0x08,
    E_CHERRY       = 0x10,
    E_PINEAPPLE    = 0x20,
    E_BANANA       = 0x40,
    E_MANGO        = 0x80,
    E_DEVIL_FRUIT  = 0x100,
    E_MY_FAVOURITE_FRUITS_FORCE8 = 0xFF // <-- Forzamos a 8 bits.
};
} // End namespace Fruits

No necesitaremos cualificar el nombre de la Fruta al completo para referirnos a ella; es decir, el nombre completo del identificador E_STAWBERRY será:

Fruits::E_STRAWBERRY

En lugar de:

Fruits::E_MY_FAVOURITE_FRUITS::E_STRAWBERRY

Este último es erróneo, porque E_MY_FAVOURITE_FRUITS no es una clase o espacio de nombres. Esto hace que sea mucho más cómodo trabajar con ellos, pero pueden dar un problema extra: Colisión de nombres.

namespace Fruits
{
enum E_MY_FAVOURITE_FRUITS
{
    E_APPLE        = 0x01,  // Fruits::E_APPLE
    E_WATERMELON   = 0x02,  // Fruits::E_WATERMELON
    E_COCONUT      = 0x04,  // Fruits::E_COCOUNUT
    E_STRAWBERRY   = 0x08,  // Fruits::E_STRAWBERRY
    E_CHERRY       = 0x10,  // Fruits::E_CHERRY
    E_PINEAPPLE    = 0x20,  // Fruits::E_PINEAPPLE
    E_BANANA       = 0x40,  // Fruits::E_BANANA
    E_MANGO        = 0x80,  // Fruits::E_MANGO
    E_DEVIL_FRUIT  = 0x100, // Fruits::E_DEVIL_FRUIT
    E_MY_FAVOURITE_FRUITS_FORCE8 = 0xFF // <-- Forzamos a 8 bits.
};
enum E_DEVIL_FRUIT // Error! Fruits::E_DEVIL_FRUIT ya existe!
{
    E_LOGIA,
    E_PARAMECIA,
    E_ZOAN,
}; } // End namespace Fruits.

Y para acabar, existe una  último comportamiento peculiar de los enumerados clásicos que los diferencia de las Clases y Estructuras:  ¡no se pueden pre-declarar!:

enum E_DEVIL_FRUIT; // Error! declaracion incompleta.
// Error! tipo no definido.
 void EatDevilFruit(E_DEVIL_FRUIT &aType, const char *apName);
enum E_DEVIL_FRUIT
{
    E_LOGIA,
    E_PARAMECIA,
    E_ZOAN,
};

Por suerte, llegan al rescate los Enumerados-Clase de C++11, tienen todo lo que sus hermanos mayores no tienen,  se les puede explicitar el tipo (asegurando el tamaño y evitando conversiones no deseadas) requieren cualificación completa de nombre (evitando colisiones de nombres) y se pueden Pre-declarar:

namespace Fruits
{
enum class E_DEVIL_FRUIT : char; // Declaracion previa de Fruits::E_DEVIL_FRUIT.
enum class E_MY_FAVOURITE_FRUITS : char // Enumerado con tipo char.
{
    E_APPLE        = 0x01,
    E_WATERMELON   = 0x02,
    E_COCONUT      = 0x04,
    E_STRAWBERRY   = 0x08,
    E_CHERRY       = 0x10,
    E_PINEAPPLE    = 0x20,
    E_BANANA       = 0x40,
    E_MANGO        = 0x80,
    E_DEVIL_FRUIT  = 0x100, // Warning: Truncamiento de valor constante.
    E_MY_FAVOURITE_FRUITS_FORCE8 = 0xFF
};
// Se usa el enumerado pre-declarado!
void EatDevilFruit(E_DEVIL_FRUIT &aType, const char *apName);
} // End namespace Fruits.

Podemos ver que los Enumerados-Clase nos han resuelto el mayor de los problemas de los enumerados tradicionales: la decisión del ancho de bits del dato ¡pasa a ser nuestra en lugar de ser algo que decidirá el compilador por nosotros!  Así que el identificador E_DEVIL_FRUIT de E_MY_FAVOURITE_FRUITS lanzará un Warning al compilar en lugar de pasar desapercibido ante nuestros ojos (podremos ignorar el Warning, ¡pero no podremos decir que no nos avisó!). También pasan a ser un dato pre-declarable, algo muy de agradecer.

La sintaxis de los Enumerados-Clase es muy parecida a la de las clases con herencia, usa la misma palabra clave y los dos puntos para referirse al tipo; también, al igual que las Clases y Estructuras,  requiere cualificación completa de nombre, esto hace que en ejemplo anterior, no nos diga que E_DEVIL_FRUIT es un identificador repetido:

namespace Fruits
{
// Fruits::E_MY_FAVOURITE_FRUITS::E_DEVIL_FRUIT no es lo mismo que
// Fruits::E_DEVIL_FRUIT.
enum class E_DEVIL_FRUIT : char
{
    E_LOGIA,
    E_PARAMECIA,
    E_ZOAN,
};
} // End namespace Fruits.

En definitiva, los nuevos Enumerados C++11 nos van a ayudar a tener un código más uniforme, más fácil de entender y menos propenso a errores ¡todo son ventajas! ¡empezad a usarlos!