Terminar sección copying collector básico

[z.facultad/75.00/informe.git] / source / d.rst

.. Introducción y breve reseña del lenguaje de programación D. También
   se presentan las necesidades particulares de D con respecto al
   recolector de basura y su estado actual.
   ESTADO: TERMINADO


.. _ref_d:

El lenguaje de programación D
============================================================================


Historia
----------------------------------------------------------------------------

D_ es un lenguaje de programación relativamente joven. Nació en 1999 y el
2 de enero de 2007 salió su `versión 1.0`__. Poco tiempo después se
continúo el desarrollo del lenguaje en la `versión 2.0`__, aún inestable
y en la cual se está experimentando principalmente sobre
multi-procesamiento.

__ `D 1.0`_
__ `D 2.0`_

El lenguaje fue diseñado e implementado por `Walter Bright`_, desarrollador
principal de Zortech C++, uno de los primeros compilador de C++ que
compilaba a código nativo, y está fuertemente influenciado éste. Sin
embargo toma muchos conceptos de otros lenguajes de más alto nivel, como
Java_ o incluso lenguajes dinámicos como Perl_.

El origen del lenguaje está plasmado en su sitio web, en donde se cita:

   It seems to me that most of the "new" programming languages fall into
   one of two categories: Those from academia with radical new paradigms
   and those from large corporations with a focus on RAD and the web. Maybe
   it's time for a new language born out of practical experience
   implementing compilers.

Esto podría traducirse como:

   Parece que la mayoría de los lenguajes de programación "nuevos" caen en
   2 categorías: aquellos académicos con nuevos paradigmas radicales
   y aquellos de grandes corporaciones con el foco en el desarrollo rápido
   y web. Tal vez es hora de que nazca un nuevo lenguaje de la experiencia
   práctica implementando compiladores.

La versión 1.0 fue más bien una etiqueta arbitraria que un indicador real
de estar ante una versión estable y completa. Luego de liberarse se
siguieron agregando nuevas características al lenguaje hasta que se empezó
el desarrollo en paralelo de la versión 2.0 al introducirse el concepto de
inmutabilidad y funciones *puras* [#dpure]_ (a mediados de 2007).

.. [#dpure] Por funciones *puras* en D_ se entiende que no tienen efectos
   colaterales. Es decir, una función pura siempre que se llame con la
   misma entrada producirá el mismo resultado. Esto es análogo a como
   funcionan los lenguajes funcionales en general, abríendo la puerta a la
   programación de estilo funcional en
   D_.

A partir de este momento la versión 1.0 quedó *teóricamente* congelada,
introduciendo solo cambios que arreglen errores (*bug fixes*),
introduciendo todos las nuevas características solamente en la versión
2.0 del lenguaje. La realidad es que se hicieron cambios incompatibles a la
versión 1.0 del lenguaje en reiteradas ocasiones, pero se fue tendiendo
a cada vez introducir menos cambios incompatibles. Sin embargo al día de
hoy el compilador de referencia sigue teniendo algunas características
presentes en la especificación del lenguaje sin implementar, por lo que
todavía no hay una implementación completa de la versión 1.0 del lenguaje,
siendo esta etiqueta todavía un poco arbitraria.

El lenguaje ha sido, hasta el desarrollo de la versión 2.0 al menos, un
esfuerzo unipersonal de `Walter Bright`_, dados sus problemas a la hora de
delegar o aceptar contribuciones. Esto motivó a la comunidad de usuarios de
D_ a crear bibliotecas base alternativas a la estándar (llamada Phobos_) en
las cuales se pudiera trabajar sin las trabas impuestas por el autor del
lenguaje.

En este contexto nacen primero Mango_ y luego Ares_. Mango_ fue creada por
Kris Macleod Bell a principios de 2004 como una biblioteca que provee
servicios básicos de entrada/salida (o *I/O* de *input/output* en inglés)
de alto rendimiento.   Siendo estos servicios algo básico lo más natural
hubiera sido que se encuentren en la biblioteca estándar de D_ pero por las
dificultades para contribuir a ésta, se desarrolla como una biblioteca
separada.   A mediados de 2004 Sean Kelly crea Ares_ , con las mismas
motivaciones pero con la intención de crear una biblioteca base (conocida
en inglés como *runtime*) que incluye los servicios básicos que necesita el
lenguaje (información de tipos, manejo de excepciones e hilos, creación
y manipulación de objetos, recolector de basura, etc.). Al poco tiempo de
liberarse Ares_, Mango_ empieza a utilizarla como biblioteca base.

Para comienzos de 2006, se empieza a trabajar en la combinación de
ambas bibliotecas para lograr una biblioteca estándar alternativa
con un alto grado de cohesión. Finalmente a principios de 2007,
coincidiendo por casualidad con la aparición de D_ 1.0, se anuncia el
resultado de este combinación bajo el nombre de Tango_, proveyendo una
alternativa completa y madura a la biblioteca estándar de D_ Phobos_.
A principios de 2008 los principales desarrolladores de Tango_ (Kris Bell,
Sean Kelly, Lars Ivar Igesund y Michael Parker publican el libro llamado
`Learn to Tango with D`_.

Esto por un lado fue un gran avance porque dio un impulso muy considerable
al lenguaje pero por otro un gran retroceso, porque todavía al día de hoy
D_ 1.0 tiene 2 bibliotecas base, una estándar pero de peor calidad y menos
mantenida y una alternativa de mayor calidad y apertura a la comunidad
(pero no estándar). El peor problema es que ambas son **incompatibles**,
por lo que un programa hecho con Tango_ no funciona con Phobos_ y viceversa
(a menos que el programador haya invertido una cantidad de tiempo no
trivial en asegurarse de que funcione con ambas).

Esto hace que la compatibilidad de programas y bibliotecas esté muy
fragmentada entre las 2 bibliotecas base. Si bien no parece que vaya
a haber solución alguna a este problema para D 1.0, D 2.0 va en camino
a solucionar este problema ya que utiliza DRuntime_, un nuevo intento de
Sean Kelly por proveer una biblioteca *runtime* bien organizada
y mantenida, que es una adaptación de la biblioteca *runtime* de Tango_
a D 2.0. Si bien todavía Tango_ no fue adaptada a D 2.0, se espera que
cuando esto pase compartan la misma biblioteca *runtime* permitiendo que
bibliotecas y programas hechos para Tango_ y Phobos_ 2.0 puedan coexistir
sin problemas.


Descripción general
----------------------------------------------------------------------------

D_ es un lenguaje de programación con sintaxis tipo C, multi-paradigma,
compilado, con *tipado* fuerte y estático, buenas capacidades tanto de
programación de bajo nivel (*system programming*) como de alto nivel.   Es
compatible de forma binaria con C (se puede enlazar código objeto C con
código objeto D). Con estas características, D_ logra llenar un vacío
importante que hay entre lo lenguajes de alto bajo nivel y los de alto
nivel [BKIP08]_. Si bien tiene herramientas de muy bajo nivel, que por lo
tanto son muy propensas a errores, da una infinidad de mecanismos para
evitar el uso de estas herramientas a menos que sea realmente necesario.
Además pone mucho énfasis en la programación confiable, para lo cual provee
muchos mecanismos para detectar errores en los programas de forma temprana.

Si puede pensarse en C++ como un "mejor C", podría decirse que D_ es
un "mejor C++", ya que el objetivo del lenguaje es muy similar a C++,
pero implementa muchas características que jamás pudieron entrar en
el estándar de C++ y lo hace de una forma mucho más limpia, ya que
no debe lidiar con problemas de compatibilidad hacia atrás, y cuenta
con la experiencia del camino recorrido por C++, pudiendo extraer de
él los mejores conceptos pero evitando sus mayores problemas también.

Otra gran diferencia con C++ es la facilidad para ser analizado
gramaticalmente (*parsing*), ya fue especialmente diseñado para ser
sencillo y a diferencia de C y C++ su gramática es independiente del
contexto (*context-free grammar*). Esto permite que D pueda ser compilado
en pequeños pasos bien separados:

1. Análisis léxico.
2. Análisis sintáctico.
3. Análisis semántico.
4. Optimizaciones.
5. Generación de código.

Esto favorece la creación de herramientas dada la facilidad de usar
solamente la cantidad de análisis necesario para cada herramienta (por
ejemplo un editor de textos puede tener hasta análisis sintáctico para
proveer resaltado o un entorno de desarrollo puede proveer herramientas de
re-factorización de código haciendo uso del análisis semántico).


Una de las características que nunca pudo entrar en el estándar de C++
es la recolección de basura. D_ no comete el mismo error.


Características del lenguaje
----------------------------------------------------------------------------

A continuación se enumeran las principales características de D_,
agrupadas por unidades funcional o paradigmas que soporta:



.. _ref_d_generic:

Programación genérica y meta-programación
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

La programación genérica se trata de la capacidad de poder desarrollar
algoritmos y estructuras independientes de los tipos que manipulan (pero de
forma segura o *type-safe*). Esto fue muy popularizado por C++ gracias a su
soporte de plantillas (*templates*) y luego otros lenguajes como Java_
y `C#`_ lo siguieron. Sin embargo otros lenguajes proveen formas más
avanzadas de programación genérica, gracias a sistemas de tipos más
complejos (como Haskell_).

La meta-programación se refiere en general a la capacidad de un lenguaje
para permitir generar código dentro del mismo programa de forma automática.
Esto permite evitar duplicación de código y fue también muy popularizado
por el soporte de *templates* de C++, aunque muchos otros lenguajes tienen
mejor soporte de meta-programación, en especial los lenguajes dinámicos
(como Python_).

D_ provee las siguientes herramientas para realizar programación genérica
y meta-programación:

``if`` estático (``static if``):
   puede verse como similar a la directiva del preprocesador de C/C++
   ``#if``, pero a diferencia de esto, en D_ el ``static if`` tiene acceso
   a todos los símbolos del compilador (constantes, tipos, variables, etc).

   Ejemplo::

      static if ((void*).sizeof == 4)
         pragma(msg, "32 bits");

   Más información en http://www.digitalmars.com/d/1.0/version.html#staticif

Inferencia de tipos básica implícita y explícita (mediante ``typeof``):
   si no se especifica un tipo al declarar una variable, se infiere del
   tipo de su inicializador.

   Ejemplo::

      static i = 5;      // i es int
      const d = 6.0;    // d es double
      auto s = "hola"; // s es string (que es un alias de char[])

   Más información en
   http://www.digitalmars.com/d/1.0/declaration.html#AutoDeclaration

   Mediante el uso de ``typeof`` se puede solicitar el tipo de una
   expresión arbitraria.

   Ejemplo::

      typeof(5 + 6.0) d; // d es double

   Más información en http://www.digitalmars.com/d/1.0/declaration.html#typeof

Iteración sobre colecciones (``foreach``):
   cualquier tipo de colección (arreglos estáticos y dinámicos, arreglos
   asociativos, clases, estructuras o delegados) puede ser iterada mediante
   la sentencia ``foreach``.

   Ejemplo::

      int[] a = [ 1, 2, 3 ];
      int total = 0;
      foreach (i; a)
         total += i;

*Templates*:
   clases y funciones pueden ser parametrizadas. Esto permite desarrollar
   algoritmos genéricos sin importar el tipo de los datos de entrada,
   siempre y cuando todos los tipos tengan una *interfaz* común.   Esto
   también es conocido como *polimorfismo en tiempo de compilación*, y es
   la forma más básica de programación genérica.

   Ejemplo::

      T sumar(T)(T x, T y) { return x + y; }
      auto i = sumar!(int)(5, 6);    // i == 11
      auto f = sumar!(float)(5, 6); // j == 11.0f

   Además se pueden definir bloques de declaraciones parametrizados (esto
   no es posible en C++), permitiendo instanciar dicho bloque con
   parámetros particulares. Esto sirve como un mecanismo para la
   reutilización de código, ya que puede incluirse un mismo bloque en
   distintos lugares (por ejemplo clases). Un bloque parametrizado puede
   verse como una especie de módulo.

   Ejemplo::

      template bloque(T, U) {
         T x;
         U foo(T y);
      }

      bloque!(int, float).x = 5;
      float f = bloque!(int, float).foo(7);

   La utilidad más prominente de los bloques parametrizados se da al
   acompañarse de *mixins*.

Instanciación implícita de funciones parametrizadas:
   el lenguaje es capaz de deducir los parámetros siempre que no hayan
   ambigüedades

   Ejemplo::

      auto i = sumar(5, 6);          // i == 11
      auto f = sumar(5.0f, 6.0f); // f == 11.0f

Especialización explícita y parcial de *templates*:
   la especialización de *templates* consiste, al igual que en C++, en
   proveer una implementación especializada para un tipo de dato (o valor)
   de los parámetros.   Especialización parcial se refiere a la capacidad
   de especializar un parámetro a través de un subtipo. Por ejemplo, se
   puede especializar un *template* para cualquier tipo de puntero, o para
   cualquier tipo de arreglo dinámico, sin necesidad de especificar el tipo
   al que apunta dicho puntero o el tipo almacenado por el arreglo.

   Ejemplo de especialización::

      T sumar(T: int)(T x, T y) { return x + y + 1; }
      auto i = sumar(5, 6);         // i == 12
      auto f = sumar(5.0f, 6.0f) // f == 11.0f

   Ejemplo de especialización parcial::

      T sumar(T: T*)(T x, T y) { return *x + *y; }
      int x = 5, y = 6;
      auto i = sumar(&x, &y); // i == 11
      float v = 5.0f, w = 6.0f;
      auto f = sumar(&v, &w); // f == 11.0f

Tipos, valores (incluyendo *strings*) y *templates* como parámetros:
   esto es otro bloque de construcción importantísimo para la programación
   genérica en D, ya que combinando *templates* que toman *strings* como
   parámetro en combinación con *string mixins* pueden hacerse toda clase
   de meta-programas.

   Ejemplo::

      template hash(string s, uint so_far=0) {
         static if (s.length == 0)
            const hash = sofar;
         else
            const hash = hash!(s[1 .. length], sofar * 11 + s[0]);
      }
      string s = hash!("hola"); // calculado en tiempo de compilación

Cantidad de parámetros variables para *templates*:
   Esto permite implementar tuplas u otros algoritmos que inherentemente
   deben tomar parámetros variables en tiempo de compilación.

   Ejemplo::

      double sumar(T...)(T t) {
         double res = 0.0;
         foreach (x; t)
            res += x;
         return res;
      }
      double d = sumar(1, 2.0, 3.0f, 4l); // d == 10.0

*CTFE* (*compile-time function execution*):
   si una función cumple ciertas reglas básicas (como por ejemplo no tener
   efectos colaterales) puede ser ejecutada en tiempo de compilación en vez
   de tiempo de ejecución. Esto permite hacer algunos cálculos que no
   cambian de ejecución en ejecución al momento de compilar, mejorando la
   performance o permitiendo formas avanzadas de metaprogramación. Esta
   característica se vuelve particularmente útil al combinarse con *string
   mixins*.

   Ejemplo::

      int factorial(int n) {
         if (n == 1)
            return 1;
         else
            return n * factorial(n - 1);
      }
      static int x = factorial(5); // calculado en tiempo de compilación
      int x = factorial(5); // calculado en tiempo de ejecución

   Esta característica es vital para evitar la duplicación de código.

*Mixins*, incluyendo *string mixins*:
   la palabra *mixin* tiene significados distintos en varios lenguajes de
   programación. En D_ *mixin* significa tomar una secuencia arbitraria de
   declaraciones e insertarla en el contexto (*scope*) actual. Esto puede
   realizarse a nivel global, en clases, estructuras o funciones. Esto
   sirve como un mecanismo para evitar duplicación de código que puede ser
   introducida por la falta de herencia múltiple.

   Ejemplo::

      class A {
         mixin bloque!(int, float);
      }
      A a = new A;
      a.x = 5;
      float f = a.foo(a.x);

      class B {
         mixin bloque!(long, double);
      }
      B b = new B;
      b.x = 5l;
      double d = a.foo(a.x);

   *String mixin* se refiere a la capacidad de *incrustar* un *string* que
   contenga un fragmento de código en un programa como si este fragmento
   hubiera sido escrito en el código fuente directamente por el
   programador.  Esto permite hacer manipulaciones arbitrariamente
   complejas en combinación con funciones ejecutadas en tiempo de
   compilación.

   Ejemplo::

      string generar_sumar(string var_x, string var_y) {
         return "return " ~ var_x ~ " + " ~ var_y ~ ";";
      }

      int sumar(int a, int b) {
         mixin(generar_sumar!("a", b"));
      }

   Más información en http://www.digitalmars.com/d/1.0/mixin.html

Expresiones ``is``:
   las *expresiones ``is``* permiten la compilación condicional basada en
   las características de un tipo. Esto se realiza en favor a una técnica
   utilizada en C++ de realizar *pattern matching* sobre los parámetros de
   las plantillas.

   Ejemplo::

      T foo(T)(T x) {
         static if (is(T == class))
            return new T;
         else
            return T.init;
      }

   Esto provee además una forma simple de reflexión en tiempo de
   compilación.

   Más información en
   http://www.digitalmars.com/d/1.0/expression.html#IsExpression



.. _ref_d_low_level:

Programación de bajo nivel (*system programming*)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Por programación de bajo nivel nos referimos a la capacidad de un lenguaje
de manipular el hardware directamente, o al menos la memoria. C es
probablemente el lenguaje de bajo nivel más popular, seguido por C++.

D_ presenta muchas características de bajo nivel:

Compila a código de máquina nativo:
   no es interpretado ni necesita una máquina virtual como otros lenguajes
   de más alto nivel como Java_, `C#`_, Python_, etc.

Provee acceso a *assembly*:
   por lo tanto, acceso directo al *hardware* y la posibilidad de utilizar
   cualquier característica de éste que no esté disponible en el lenguaje.

   Una ventaja sobre C y C++ es que el lenguaje *assembly* utilizado dentro
   de D_ está especificado, por lo que se puede mantener la portabilidad
   entre compiladores incluso cuando se utiliza *assembly* (mientras que no
   se cambie de arquitectura, por supuesto).

``goto``:
   al igual que C y C++, D_ provee la flexibilidad del uso de ``goto``.

Compatibilidad con C:
   soporta todos los tipos de C y es ABI [#abi]_ compatible con éste. Esto
   permite enlazar archivos objeto estándar de C y D_ en un mismo programa.
   Además permite interoperar con C a través de ``extern (C)``.

   .. [#abi] Interfaz de Aplicación Binaria (del inglés *Application Binary
      Interface*).

   Ejemplo::

      extern (C) printf(const char* format, ...);
      printf("3 + 5 == %d\n", 3 + 5); // llama al printf de C

Manejo de memoria explícito:
   permite alocar estructuras en el *stack* o en el *heap*, haciendo uso de
   los servicios del sistema operativo o la biblioteca estándar de C.

Objetos y arreglos *livianos*:
   por objetos *livianos* se entiende no-polimórficos. Es decir, un
   agrupamiento de variables análogo al ``struct`` de C, sin tabla virtual
   ni otro tipo de *overhead*. Los arreglos *livianos* son arreglos
   estáticos como en C, cuyo tamaño es fijo, también sin ningún tipo de
   *overhead* como C. Además puede alocarse un arreglo dinámicamente usando
   ``malloc()`` y utilizar el operador ``[]`` para accederlo.

   Esto también permite interoperar con C, ya que pueden definirse
   ``structs`` y arreglos que pueden ser intercambiados con dicho lenguaje
   sin problemas.

   Ejemplo::

      struct timeval {
         time_t         tv_sec;
         suseconds_t tv_usec;
      }
      extern (C) {
         void* malloc(size_t);
         size_t strlen(const char *);
         int gettimeofday(timeval *, void *);
      }
      char* s = cast(char*) malloc(2);
      s[0] = 'C';
      s[1] = '\0';
      size_t l = strlen(s); // l == 1
      timeval tv;
      gettimeofday(&tv, null);

Rendimiento:
   la :ref:`ref_d_generic` permite realizar muchas optimizaciones ya que se
   resuelve en tiempo de compilación y por lo tanto aumentando la
   *performance* en la ejecución.

Número de punto flotante de 80 bits:
   El tipo ``real`` de D_ tiene precisión de 80 bits si la plataforma lo
   soporta (por ejemplo en i386).

Control de alineación de miembros de una estructura:
   Mediante ``align`` se puede especificar la alineación a tener en una
   estructura.

   Ejemplo::

      align (1)
      struct paquete_de_red {
         char   tipo;
         short valor;
      }
      // paquete_de_red.sizeof == 3



.. _ref_d_high_level:

Programación de alto nivel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Programa de alto nivel se refiere a construcciones más avanzadas que un
loop. Expresiones semánticamente más ricas que permiten mayor expresividad
al programador o le permiten focalizarse de mejora manera en los algoritmos
independizándose del *hardware* o de como funciona una computadora. Es
exactamente el opuesto a :ref:`ref_d_low_level`.

En general estas características tiene como efecto secundario una mejora de
la productividad de los programadores. D_ adopta herramientas de muchos
lenguajes de alto nivel, como Java_ y Python_, por ejemplo:

Manejo automático de memoria:
   al igual que C/C++ y prácticamente cualquier lenguaje imperativo maneja
   automáticamente el *stack*, pero a diferencia de la mayoría de los
   lenguajes de bajo nivel, D_ permite manejar el *heap* de manera
   automática también a través de un *recolección de basura*.

Sistema de paquetes y módulos (similar a Java_ o Python_):
   un módulo es una unidad que agrupa clases, funciones y cualquier otra
   construcción de lenguaje. Un paquete es una agrupación de módulos. D_
   asocia un módulo a un archivo fuente (y un archivo objeto cuando éste es
   compilado) y un paquete a un directorio. A diferencia de C/C++ no
   necesita de un preprocesador para incluir declaraciones de otros
   *módulos* (en C/C++ no existe el concepto de módulo, solo de unidades de
   compilación).

   Ejemplo:

   ``a.d``::

      module a;
      void f() {}

   ``b.d``::

      module b;
      void f() {}

   ``c.d``::

         module c;
         import a;
         import b: f;
         a.f();
         b.f();
         f(); // ejecuta b.f()

Funciones y delegados:
   las funciones pueden ser sobrecargadas (funciones con el mismo nombre
   pero distinta cantidad o tipo de parámetros), pueden especificarse
   argumentos de entrada, salida o entrada/salida, argumentos por omisión
   o argumentos evaluados de forma perezosa (*lazy*). Además pueden tener
   una cantidad de argumentos variables pero manteniendo información de
   tipos (más seguro que C/C++).

   Los *delegados* son punteros a función con un contexto asociado. Este
   contexto puede ser un objeto (en cuyo caso la función es un método) o un
   *stack frame* (en cuyo caso la función es una función anidada).

   Además de esto los delegados son ciudadanos de primera clase
   [#1stclasscity]_, disponiendo de forma literal (delegado anónimo), lo
   que permite construcciones de alto nivel muy conveniente. Los argumentos
   evaluados de forma perezosa no son más que un delegado que se ejecuta
   solo cuando es necesario.

   .. [#1stclasscity] Por ciudadano de primera clase se entiende que se trata
      de un tipo soportado por completo por el lenguaje, disponiendo de
      expresiones literales anónimas, pudiendo ser almacenados en variables,
      estructuras de datos, teniendo una identidad intrínseca, más allá de un
      nombre dado, etc. En realidad los arreglos asociativos no pueden ser
      expresados como literales anónimos pero sí tienen una sintaxis especial
      soportada directamente por el lenguaje.

   Ejemplo::

      bool buscar(T[] arreglo, T item, bool delegate(T x, T y) igual) {
         foreach (t, arreglo)
            if (igual(t, elemento))
               return true;
         return false;
      }
      struct Persona {
         string nombre;
      }
      Persona[] personas;
      // llenas personas
      Persona p;
      p.nombre = "Carlos";
      bool encontrado = buscar(personas, p,
                                       (Persona x, Persona y) {
                                          return x.nombre == y.nombre;
                                       }
                                 );

Arreglos *dinámicos* y arreglos asociativos:
   los arreglos *dinámicos* son arreglos de longitud variable manejados
   automáticamente por el lenguaje (análogos al ``std::vector`` de C++).
   Soportan concatenación (a través del operador ``~``), rebanado
   o *slicing* (a través del operador ``[x..y]``) y chequeo de límites
   (*bound checking*).

   Los arreglos asociativos (también conocidos como *hashes*
   o diccionarios) también son provistos por el lenguaje.

   Ambos son ciudadanos de primera clase, disponiendo de forma literal.

   Ejemplo::

      int[] primos = [ 2, 3, 5, 7, 11, 13, 17, 19 ];
      primos ~= [ 23, 29 ];
      auto menores_que_10 = primos[0..4]; // [ 2, 3, 5, 7 ]
      int[string] agenda;
      agenda["Pepe"] = 5555_1234;

*Strings*:
   al igual que los delegados y arreglos dinámicos y asociativos, los
   *strings* son ciudadanos de primera clase, teniendo forma literal
   y siendo codificados en UTF-8/16/32. Son un caso particular de arreglo
   dinámico y es posible utilizarlos en sentencias ``switch``/``case``.

   Ejemplo::

      string s = "árbol";

      switch (s) {
         case "árbol":
            s = "tree";
         default:
            s = "";
      }

``typedef`` y ``alias``:
   el primero define un nuevo tipo basado en otro. A diferencia de C/C++ el
   tipo original no puede ser implícitamente convertido al tipo nuevo
   (excepto valores literales), pero la conversión es válida en el otro
   sentido (similar a los ``enum`` en C++). Por el contrario, ``alias`` es
   análogo al ``typedef`` de C/C++ y simplemente es una forma de referirse
   al mismo tipo con un nombre distinto.

   Ejemplo::

      typedef int tipo;
      int foo(tipo x) {}
      tipo t = 10;
      int i = 10;
      foo(t);
      foo(i); // error, no compila
      alias tipo un_alias;
      un_alias a = t;
      foo(a);

Documentación embebida:
   D_ provee un sistema de documentación embebida, análogo a lo que provee
   Java_ o Python_ en menor medida. Hay comentarios especiales del código
   que pueden ser utilizados para documentarlo de forma tal que luego el
   compilador pueda extraer esa información para generar un documento.

   Más información en http://www.digitalmars.com/d/1.0/ddoc.html

Números complejos:
   D_ soporta números complejos como ciudadanos de primera clase. Soporta
   forma literal de números imaginarios y complejos.

   Ejemplo::

      ifloat im = 5.0i;
      float   re = 1.0;
      cfloat c   = re + im; // c == 1.0 + 5.0i



Programación orientada a objetos
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

La orientación a objetos es probablemente el paradigma más utilizado en la
actualidad a la hora de diseñar e implementar un programa. D_ provee muchas
herramientas para soportar este paradigma de forma confiable. Entre las
características más salientes se encuentran:

Objetos *pesados*:
   objetos polimórficos como los de cualquier lenguaje con orientación real
   a objetos. Estos objetos poseen una tabla virtual para *dispatch*
   dinámico, todos los métodos son virtuales a menos que se indique lo
   contrario y tienen semántica de referencia [#drefsem]_. Estos objetos
   tienen un *overhead* comparados a los objetos *livianos* pero aseguran
   una semántica segura para trabajar con orientación a objetos, evitando
   problemas con los que se enfrenta C++ (como *slicing* [#dslicing]_)
   debido a que permite semántica por valor [#dvalsem]_.

   .. [#drefsem] Semántica de referencia significa que el tipo es tratado como
      si fuera un puntero. Nunca se hacen copias del objeto, siempre se pasa
      por referencia.

   .. [#dslicing] Este problema se da en C++ cuando se pasa una clase derivada
      a una función que acepta una clase base por valor como parámetro. Al
      realizarse una copia de la clase con el constructor de copia de la clase
      base, se pierden (o *rebanan*) los atributos de la clase derivada, y la
      información de tipos en tiempo de ejecución (*RTTI*).

   .. [#dvalsem] Semántica de valor significa que el tipo es tratado como si
      fuera un valor concreto. En general se pasa por valor y se hacen copias
      a menos que se utilice explícitamente un puntero.

   D_ además soporta tipos de retorno covariantes para funciones virtuales.
   Esto significa que una función sobreescrita por una clase derivada puede
   retornar un tipo que sea derivado del tipo retornado por la función
   original sobreescrita.

   Ejemplo::

      class A { }
      class B : A { }

      class Foo {
         A test() { return null; }
      }

      class Bar : Foo {
         B test() { return null; } // sobreescribe y es covariante con Foo.test()
      }

   Más información en http://www.digitalmars.com/d/1.0/function.html

Interfaces:
   D_ no soporta herencia múltiple pero sí interfaces. Una interfaz es
   básicamente una tabla virtual, una definición de métodos virtuales que
   debe proveer una clase. Las interfaces no proveen una implementación de
   dichos métodos, ni pueden tener atributos. Esto simplifica mucho el
   lenguaje y no se pierde flexibilidad porque puede conseguirse el mismo
   efecto de tener herencia múltiple a través de interfaces y *mixins* para
   proveer una implementación o atributos en común a varias clases que
   implementan la misma interfaz.

Sobrecarga de operadores:
   la sobrecarga de operadores permite que un objeto tenga una sintaxis
   similar a un tipo de dato nativo. Esto es muy importante además para la
   programación genérica.

Clases anidadas:
   al igual que C (con respecto a ``struct``) y C++, pueden anidarse clases
   dentro de clases. D_ sin embargo provee la posibilidad de acceder
   a atributos de la instancia exterior desde la anidada.

   Ejemplo::

      class Exterior {
         int m;
         class Anidada {
            int foo() {
               return m; // ok, puede acceder a un miembro de Exterior
            }
         }
      }

   Esto tiene un pequeño *overhead* ya que la clase ``Anidada`` debe
   guardar un puntero a la clase ``Exterior``. Si no se necesita este
   comportamiento es posible evitar este *overhead* utilizando ``static``,
   en cuyo caso solo puede acceder a atributos estáticos de la clase
   ``Exterior``.

   Ejemplo::

      class Exterior {
         int m;
         static int n;
         static class Anidada {
            int foo() {
               //return m; // error, miembro de Exterior
               return n; // ok,   miembro estático de Exterior
            }
         }
      }


Propiedades (*properties*):
   en D_ se refiere a funciones miembro que pueden ser tratadas
   sintácticamente como campos de esa clase/estructura.

   Ejemplo::

      class Foo {
         int data() { return _data; } // propiedad de lectura
         int data(int value) { return _data = value; } // de escritura
         private int _data;
      }
      Foo f = new Foo;
      f.data = 1;       // llama a f.data(1)
      int i = f.data; // llama a f.data()

   Además tipos nativos, clases, estructuras y expresiones tienen
   *properties* predefinidos, por ejemplo:

   ``sizeof``:
      tamaño ocupado en memoria (ejemplo: ``int.sizeof`` -> 4).

   ``init``:
      valor de inicialización por omisión (ejemplo: ``float.init`` -> *NaN*
      [#dnan]_).

   .. [#dnan] Del inglés *Not A Number*, es un valor especial que indica que
      estamos ante un valor inválido.

   ``stringof``:
      representación textual del tipo (ejemplo: ``(1+2).stringof`` -> ``"1
      + 2"``).

   ``mangleof``:
      representación textual del tipo *mutilado* [#dmangle]_.

   .. [#dmangle] *Name mangling* es el nombre dado comunmente a una técnica
      necesaria para poder sobrecargar nombres de símbolos. Consiste en
      codificar los nombres de las funciones tomando como entrada el nombre de
      la función y la cantidad y tipo de parámetros, asegurando que dos
      funciones con el mismo nombre pero distintos parámetros (sobrecargada)
      tengan nombres distintos.

   ``alignof``
      alineación de una estructura o tipo.

   Estos son solo los *properties* predefinidos para todos los tipos, pero
   hay una cantidad considerable de *properties* extra para cada tipo.

   Más información sobre *properties* de clases en
   http://www.digitalmars.com/d/1.0/property.html#classproperties y sobre
   *properties* predefinidos en
   http://www.digitalmars.com/d/1.0/property.html



Programación confiable
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Programación confiable se refiere a las capacidades o facilidades que
provee el lenguaje para evitar fallas de manera temprano (o la capacidad de
evitar que ciertas fallas puedan existir directamente). D_ presta
particular atención a esto y provee las siguientes herramientas:

Excepciones:
   D_ soporta excepciones de manera similar a Java_: provee ``try``,
   ``catch`` y ``finally``. Esto permite que los errores difícilmente pasen
   silenciosamente sin ser detectados.

``assert``:
   es una condición que debe cumplirse siempre en un programa, como un
   chequeo de integridad. Esto es muy utilizado en C/C++, donde
   ``assert()`` es una *macro* que solo se compila cuando la *macro*
   ``NDEBUG`` no está definida. Esto permite eliminar los chequeos de
   integridad del programa, que pueden ser costosos, para versiones que se
   suponen estables.

   D_ lleva este concepto más allá y hace al ``assert`` parte del lenguaje.
   Si una verificación no se cumple, lanza una excepción. El ``assert`` no
   es compilado cuando se utiliza una opción del compilador.

   Ejemplo::

      File f = open("archivo");
      assert (f.ok());

Diseño por contrato:
   el diseño por contrato es un concepto introducido por el lenguaje
   Eiffel_ a mediados/finales de los '80. Se trata de incorporar en el
   lenguaje las herramientas para poder aplicar verificaciones formales
   a las interfaces de los programas.

   D_ implementa las siguientes formas de diseño por contrato (todas se
   ejecutan siempre y cuando no se compile en modo *release*, de manera de
   no sacrificar *performance* cuando es necesario):

   Pre y post condiciones:
      Ejemplo::

         double raiz_cuadrada(double x)
         in { // pre-condiciones
            assert (x >= 0.0);
         }
         out (resultado) { // post-condiciones
            assert (resultado >= 0.0);
            if (x < 1.0)
               assert (resultado < x);
            else if (x > 1.0)
               assert (resultado > x);
            else
               assert (resultado == 1);
         }
         body {
            // implementación
         }

   Invariantes de representación:
      La invariante de representación es un método de una clase
      o estructura que es verificada cuando se completa su construcción,
      antes de la destrucción, antes y después de ejecutar cualquier
      función miembro pública y cuando se lo requiere de forma explícita
      utilizando ``assert``.

      Ejemplo::

         class Fecha {
               int dia;
               int hora;
               invariant() {
                  assert(1 <= dia && dia <= 31);
                  assert(0 <= hora && hora < 24);
               }
         }

   Más información en http://www.digitalmars.com/d/1.0/dbc.html

Pruebas unitarias:
   es posible incluir pequeñas pruebas unitarias en el lenguaje. Éstas son
   ejecutadas (cuando no se compila en modo *release*) al comenzar el
   programa, antes de que la función ``main()``.

   Ejemplo::

      unittest {
         Fecha fecha;
         fecha.dia = 5;
         assert (fecha.dia == 5);
         assert (fecha);
      }

Orden de construcción estática:
   a diferencia de C++, D_ garantiza el orden de inicialización de los
   módulos. Si bien en C++ no hay módulos si no unidades de compilación, es
   posible que se ejecute código antes del ``main()`` en C++, si hay, por
   ejemplo, instancias globales con un constructor definido. C++ no
   garantiza un orden de inicialización, lo que trae muchos problemas. En
   D_ se define el orden de inicialización y es el mismo orden en que el
   usuario importa los módulos.

Inicialización garantizada:
   todas las variables son inicializadas por el lenguaje (a menos que el
   usuario pida explícitamente que no lo sean). Siempre que sea posible se
   elijen valores de inicialización que permitan saber al programador que
   la variable no fue inicializada explícitamente, de manera de poder
   detectar errores de manera temprana.

   Ejemplo::

      double d;         // inicializado a NaN
      int x;             // inicializado a 0
      Fecha f;          // inicializado a null
      byte[5] a;       // inicializados todos los valores a 0
      long l = void; // NO inicializado (explícitamente)

*RAII* (*Resource Adquisition Is Initialization*):
   es una técnica muy utilizada en C++ que consiste en reservar recursos
   por medio de la construcción de un objeto y liberarlos cuando se libera
   éste. Al llamarse al destructor de manera automática cuando se sale del
   *scope*, se asegura que el recurso será liberado también.

   Esta técnica es la base para desarrollar código seguro en cuanto
   a excepciones (*exception-safe*) [SUTT99]_.

   En D_ no es tan común utilizar *RAII* dada la existencia del recolector
   de basura (en la mayoría de los casos el recurso a administrar es
   sencillamente memoria). Sin embargo en los casos en donde es necesario,
   puede utilizarse *RAII* mediante la utilización de la palabra reservada
   ``scope``, que limita la vida de un objeto un bloque de código.

   Ejemplo::

      class Archivo {
         this() { /* adquiere recurso */ }
         ~this() { /* libera recurso */ }
      }
      void f() {
         scope Archivo archivo = new Archivo;
         // uso de archivo
      } // en este punto se llama al destructor de archivo

Guardias de bloque (*scope guards*):
   además de poder limitar la vida de una instancia a un *scope*, es
   posible especificar un bloque de código arbitrario a ejecutar al
   abandonar un *scope*, ya sea cuando se sale del *scope* normalmente
   o por una falla.

   Ejemplo::

      int f(Lock lock) {
         lock.lock();
         scope (exit)
            lock.unlock();                  // ejecutado siempre que salga de f()
         auto trans = new Transaccion;
         scope (success)
            trans.commit();                // ejecutado si sale con "return"
         scope (failure)
            trans.rollback();             // ejecutado si sale por una excepción
         if (condicion)
            throw Exception("error"); // ejecuta lock.unlock() y trans.rollback()
         else if (otra_condicion)
            return 5;                         // ejecuta lock.unlock() y trans.commit()
         return 0;                            // ejecuta lock.unlock() y trans.commit()
      }

   Esta es una nueva forma de poder escribir código *exception-safe*,
   aunque el programador debe tener un poco más de cuidado de especificar
   las acciones a ejecutar al finalizar el *scope*.

Primitivas de sincronización de hilos:
   la programación multi-hilo está directamente soportada por el lenguaje,
   y se provee una primitiva de sincronización al igual que Java_. La
   palabra reservada ``synchronized`` puede aparecer como modificador de
   métodos (en cuyo caso se utiliza un *lock* por clase para sincronizar)
   o como una sentencia, en cuyo caso se crea un *lock* global por cada
   bloque ``synchronized`` a menos que se especifique sobre qué objeto
   realizar la sincronización. Por ejemplo::

      class Foo {
         synchronized void bar() { /* cuerpo */ }
      }

   Es equivalente a::

      class Foo {
         void bar() {
            synchronized (this) { /* cuerpo */ }
         }
      }


Compiladores
----------------------------------------------------------------------------

Hay, hasta el momento, 3 compiladores de D_ de buena calidad: DMD_, GDC_
y LDC_.

DMD_ es el compilador de referencia, escrito por `Walter Bright`_. El
*front-end* [#frontend]_ de este compilador ha sido liberado bajo licencia
Artistic_/GPL_ y es utilizado por los otros dos compiladores, por lo
tanto en realidad hay solo un compilador disponible con 3 *back-ends*
[#backend]_ diferentes.

.. [#frontend] *Front-end* es la parte del compilador encargada de hacer el
   análisis léxico, sintáctico y semántico del código fuente, generando una
   representación intermedia que luego el *back-end* convierte a código de
   máquina.

.. [#backend] El *back-end* es la parte del compilador encargada de convertir
   la representación intermedia generada por el *front-end* a código de
   máquina.

Con `DMD 1.041`__ se publicó el código fuente completo del compilador,
pero con una licencia muy restrictiva para uso personal, por lo que el
único efecto logrado por esto es que la gente pueda mandar parches
o correcciones del compilador pero no lo convierte en `Software Libre`_,
siendo el único de los 3 compiladores que no tiene esta característica.

__ http://www.digitalmars.com/d/1.0/changelog.html#new1_041

El compilador GDC_ es el *front-end* de DMD_ utilizando al compilador GCC_
como *back-end*. Fue un muy buen compilador pero en la actualidad está
abandonado. No hay un *release* desde agosto de 2007 y no hay
actualizaciones serias del código desde mediados de 2008, por lo que no
parece haber muchas probabilidades de que se siga manteniendo.

LDC_ es lo opuesto; un compilador joven, nacido a mediados de 2007 (aunque
vio la luz un año después aproximadamente), su primer *release* fue
a principios de 2009 y tuvo un crecimiento excepcional. En la actualidad
inclusive pasa más pruebas de estrés que el compilador de referencia DMD_.
Como *back-end* utiliza LLVM_, otro proyecto joven y con una tasa de
crecimiento muy alta.

Además de estos compiladores hay varios otros experimentales, pero ninguno
de ellos de calidad suficiente todavía. Por ejemplo hay un compilador
experimental que emite *CIL* (*Common Intermediate Language*), el
*bytecode* de `.NET`_, llamado DNet_. También hay un *fron-end* escrito en
D_, llamado Dil_

Originalmente, dado que GDC_ estaba siendo mantenido y que LDC_ no existía,
este trabajo iba a ser realizado utilizando GDC_ como compilador, dado que
al ser `Software Libre`_ podía ser modificado de ser necesario. Finalmente,
gracias a la excepcional tasa de crecimiento de LDC_ y al abandono de GDC_
se terminó desarrollando el trabajo utilizando LDC_.



.. include:: links.rst

.. vim: set ts=3 sts=3 sw=3 et tw=78 :