.. 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, CORREGIDO, REVISADO
+ ESTADO: TERMINADO, CORREGIDO
+.. highlight:: d
+
.. _d_lang:
El lenguaje de programación D
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.
+el desarrollo del lenguaje en la `versión 2.0`__, que pasó a ser considerada
+estable aproximadamente en junio de 2010 con el lanzamiento del libro "The
+D Programming Language" [ALX10]_, pero aún es un trabajo en progreso.
__ `D 1.0`_
__ `D 2.0`_
embargo toma muchos conceptos de otros lenguajes de más alto nivel, como Java_
o incluso lenguajes dinámicos como Perl_, Python_ y Ruby_.
-El origen del lenguaje está plasmado en su sitio web, en donde se cita:
+El origen del lenguaje está plasmado en su sitio web, en donde se cita
+[DWEB]_:
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
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 considerable en asegurarse de que funcione con ambas).
+tiempo considerable en asegurarse que funcione con ambas).
Esto hace que la compatibilidad de programas y bibliotecas esté muy
fragmentada entre las dos 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
- y Phobos_ 2.0 puedan coexistir sin problemas.
+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`_. Sin embargo
+Tango_ no fue adaptada a `D 2.0`_ todavía, y no hay muchas perspectivas de que
+sea portada en algún momento, por un lado porque en general la comunidad sigue
+fragmentada entre muchos usuarios de `D 1.0`_ que no están contentos con los
+cambios introducidos en `D 2.0`_, en su mayoría usuarios de Tango_, y que no
+planean migrar a esa versión; y por otro porque el desarrollo de Phobos_ 2.0
+se ha abierto mucho y tiene muchos colaboradores, por lo tanto la mayor parte
+de la gente que utiliza `D 2.0`_ está contenta con el estado de Phobos_ 2.0.
Descripción general
por C++, pudiendo extraer de él los mejores conceptos pero evitando sus
mayores problemas.
-Otra gran diferencia con C++ es la facilidad para ser analizado
-sintácticamente (*parsing*), ya que 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.
+Una gran diferencia con C++ es que el análisis sintáctico (*parsing*) se puede
+realizar sin ningún tipo de análisis semántico, dado que a diferencia de éstos
+su gramática es libre de contexto (*context-free grammar*). Esto acelera
+y simplifica considerablemente el proceso de compilación [WBB10]_ [DWOV]_.
-Esto favorece la creación de herramientas dada la facilidad de usar solamente
-la cantidad de análisis necesario para cada una (por ejemplo un editor de
-textos puede tener hasta análisis sintáctico para proveer resaltado o un
-entorno de desarrollo puede proveer herramientas para re-factorizar el 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.
+Otra gran diferencia es que D_ decide incluir recolección de basura como parte
+del lenguaje, mientras que en el comité de estandarización de C++ nunca se
+llegó a un consenso para su incorporación.
Características del lenguaje
----------------------------------------------------------------------------
A continuación se enumeran las principales características de D_, agrupadas
-por unidades funcionales o paradigmas que soporta:
+por unidades funcionales o paradigmas que soporta [DWLR]_:
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).
+ Esta construcción es similar a la directiva del preprocesador de C/C++
+ ``#if``, pero a diferencia de éste, el ``static if`` de D_ tiene acceso
+ a todos los símbolos del compilador (constantes, tipos, variables, etc)
+ [DWSI]_.
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 valor de inicialización.
+ Si no se especifica un tipo al declarar una variable, se infiere a partir
+ del tipo de su valor de inicialización [DWIN]_.
Ejemplo::
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.
+ arbitraria [DWTO]_.
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
+ Cualquier tipo de colección (arreglos estáticos y dinámicos, arreglos
asociativos, clases, estructuras o delegados) puede ser iterada mediante la
- sentencia ``foreach``.
+ sentencia ``foreach`` [DWFE]_.
Ejemplo::
total += i;
*Templates*
- clases y funciones pueden ser generalizadas. Esto permite desarrollar
+ Tanto clases como funciones pueden ser generalizadas. 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.
+ básica de programación genérica [DWTP]_.
Ejemplo::
La utilidad más prominente de los bloques generalizados se da al
acompañarse de *mixins*.
-Instanciación implícita de funciones generalizadas
- el lenguaje es capaz de deducir los parámetros siempre que no hayan
- ambigüedades.
+ Además las *templates* de D_ tienen las siguientes características
+ destacables:
- Ejemplo::
+ Instanciación implícita de funciones generalizadas
+ El lenguaje es capaz de deducir los parámetros siempre que no hayan
+ ambigüedades.
- auto i = sumar(5, 6); // i == 11
- auto f = sumar(5.0f, 6.0f); // f == 11.0f
+ Ejemplo::
-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.
+ auto i = sumar(5, 6); // i == 11
+ auto f = sumar(5.0f, 6.0f); // f == 11.0f
- Ejemplo de especialización::
+ 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.
- 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::
- Ejemplo de especialización parcial::
+ 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
- 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
+ Ejemplo de especialización parcial::
-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.
+ 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
- Ejemplo::
+ Tipos, valores (incluyendo *strings*) y *templates* como parámetros
+ Este 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.
- template hash(string s, uint so_far=0) {
- static if (s.length == 0)
- const hash = so_far;
- else
- const hash = hash!(s[1 .. length], so_far * 11 + s[0]);
- }
- string s = hash!("hola"); // calculado en tiempo de compilación
+ Ejemplo::
-Cantidad de parámetros variables para *templates*
- Esto permite implementar tuplas u otros algoritmos que inherentemente deben
- tomar una cantidad variable de parámetros en tiempo de compilación.
+ template hash(string s, uint so_far=0) {
+ static if (s.length == 0)
+ const hash = so_far;
+ else
+ const hash = hash!(s[1 .. length], so_far * 11 + s[0]);
+ }
+ string s = hash!("hola"); // calculado en tiempo de compilación
- Ejemplo::
+ Cantidad de parámetros variables para *templates*
+ Esta característica permite implementar tuplas y otros algoritmos que
+ inherentemente deben tomar una cantidad variable de parámetros en tiempo
+ de compilación.
- 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
+ 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
+ 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 el rendimiento
o permitiendo formas avanzadas de meta-programación. Esta característica se
- vuelve particularmente útil al combinarse con *string mixins*.
+ vuelve particularmente útil al combinarse con *string mixins* [DWCF]_.
Ejemplo::
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.
+ Esta característica es muy importante para evitar la duplicación de código.
*Mixins*, incluyendo *string mixins*
- la palabra *mixin* tiene significados distintos en varios lenguajes de
+ 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.
+ introducida por la falta de herencia múltiple [DWMT]_.
Ejemplo::
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.
+ con funciones ejecutadas en tiempo de compilación [DWME]_ [DWMX]_.
Ejemplo::
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.
+ Las *expresiones ``is``* permiten la compilación condicional basada en las
+ características de un tipo [DWIE]_.
Ejemplo::
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
-
.. _d_low_level:
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.
+ Los programas generados por D_ no son interpretados ni necesitan una
+ máquina virtual como otros lenguajes de más alto nivel como Java_, `C#`_,
+ Python_, etc [DWOV]_.
-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.
+*Assembly* empotrado
+ Provee 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).
+ cambie de arquitectura, por supuesto) [DWIA]_.
``goto``
- al igual que C y C++, D_ provee la flexibilidad del uso de ``goto``.
+ Al igual que C y C++, D_ provee la flexibilidad del uso de ``goto``
+ [DWGT]_.
Compatibilidad con C
- soporta todos los tipos de C y es ABI [#abi]_ compatible con éste. Esto
+ 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)``.
+ Además permite interoperar con C a través de ``extern (C)`` [DWCC]_.
.. [#abi] Interfaz de Aplicación Binaria (del inglés *Application Binary
Interface*).
printf("3 + 5 == %d\n", 3 + 5); // llama al printf de C
Manejo de memoria explícito
- permite asignar estructuras en el *stack* o en el *heap*, haciendo uso de
- los servicios del sistema operativo o la biblioteca estándar de C.
+ Permite asignar estructuras en el *stack* o en el *heap*, haciendo uso de
+ los servicios del sistema operativo o la biblioteca estándar de C [DWMM]_.
Objetos y arreglos *livianos*
- por objetos *livianos* se entiende no-polimórficos. Es decir, un
+ 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 asignarse un arreglo dinámicamente usando ``malloc()``
- y utilizar el operador ``[]`` para accederlo.
+ y utilizar el operador ``[]`` para accederlo [DWST]_ [DWCL]_.
Esto también permite interoperar con C, ya que pueden definirse ``structs``
y arreglos que pueden ser intercambiados con dicho lenguaje sin problemas.
gettimeofday(&tv, null);
Rendimiento
- la :ref:`d_generic` permite realizar muchas optimizaciones ya que se
+ La :ref:`d_generic` permite realizar muchas optimizaciones ya que se
resuelve en tiempo de compilación y por lo tanto aumenta el rendimiento en
- la ejecución.
+ la ejecución [DWTP]_.
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).
+ soporta (por ejemplo en i386) [DWTY]_.
Control de alineación de miembros de una estructura
Mediante ``align`` se puede especificar la alineación a tener en una
- estructura.
+ estructura [DWAL]_.
Ejemplo::
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
+ 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 *recolector de basura*.
+ también a través de un *recolector de basura* [DWGC]_.
Sistema de paquetes y módulos (similar a Java_ o Python_)
- un módulo es una unidad que agrupa clases, funciones y cualquier otra
+ 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).
+ no existe el concepto de módulo, solo de unidades de compilación) [DWMO]_.
Ejemplo:
f(); // ejecuta b.f()
Funciones y delegados
- las funciones pueden ser sobrecargadas (funciones con el mismo nombre pero
+ 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++).
+ C/C++) [DWFU]_.
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
);
Arreglos *dinámicos* y arreglos asociativos
- los arreglos *dinámicos* son arreglos de longitud variable manejados
+ 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*).
+ (a través del operador ``[x..y]``) y chequeo de límites (*bound checking*)
+ [DWAR]_.
Los arreglos asociativos (también conocidos como *hashes* o diccionarios)
- también son provistos por el lenguaje.
+ también son provistos por el lenguaje [DWAA]_.
Ambos son ciudadanos de primera clase, disponiendo de forma literal.
agenda["Pepe"] = 5555_1234;
*Strings*
- al igual que los delegados y arreglos dinámicos y asociativos, los
+ 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``.
+ posible utilizarlos en sentencias ``switch``/``case`` [DWSR]_.
Ejemplo::
}
``typedef`` y ``alias``
- el primero define un nuevo tipo basado en otro. A diferencia de C/C++ el
+ 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.
+ con un nombre distinto [DWDC]_.
Ejemplo::
D_ provee un sistema de documentación embebida, análogo a lo que proveen
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
+ compilador pueda extraer esa información para generar un documento [DWDO]_.
Números complejos
D_ soporta números complejos como ciudadanos de primera clase. Soporta
- forma literal de números imaginarios y complejos.
+ forma literal de números imaginarios y complejos [DWTY]_.
Ejemplo::
características más salientes se encuentran:
Objetos *pesados*
- objetos polimórficos como los de cualquier lenguaje con orientación real
+ Objetos polimórficos como los de cualquier lenguaje con orientación real
a objetos. Estos objetos poseen una tabla virtual para despacho 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]_.
+ semántica por valor [#dvalsem]_ [DWCL]_.
.. [#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
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.
+ original sobreescrita [DWFU]_.
Ejemplo::
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
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.
+ misma interfaz [DWIF]_.
Sobrecarga de operadores
- la sobrecarga de operadores permite que un objeto tenga una sintaxis
+ 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.
+ programación genérica [DWOO]_.
Clases anidadas
- al igual que C (con respecto a ``struct``) y C++, pueden anidarse clases
+ 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.
+ a atributos de la instancia exterior desde la anidada [DWNC]_.
Ejemplo::
Propiedades (*properties*)
- en D_ se refiere a funciones miembro que pueden ser tratadas
- sintácticamente como campos de esa clase/estructura.
+ En D_ se refiere a funciones miembro que pueden ser tratadas
+ sintácticamente como campos de esa clase/estructura [DWPR]_.
Ejemplo::
*properties* predefinidos, por ejemplo:
``sizeof``
- tamaño ocupado en memoria (ejemplo: ``int.sizeof`` -> 4).
+ Tamaño ocupado en memoria (ejemplo: ``int.sizeof`` -> 4).
``init``
- valor de inicialización por omisión (ejemplo: ``float.init`` -> *NaN*
+ 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 símbolo o expresión (ejemplo:
+ Representación textual del símbolo o expresión (ejemplo:
``(1+2).stringof`` -> ``"1 + 2"``).
``mangleof``
- representación textual del tipo *mutilado* [#dmangle]_.
+ 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
tengan nombres distintos.
``alignof``
- alineación de una estructura o tipo.
+ 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.
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.
+ silenciosamente sin ser detectados [DWEX]_.
``assert``
- es una condición que debe cumplirse siempre en un programa, como un chequeo
+ 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.
+ D_ lleva este concepto más allá y hace al ``assert`` parte del lenguaje
+ [DWCP]_. 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::
assert (f.ok());
Diseño por contrato
- el diseño por contrato es un concepto introducido por el lenguaje Eiffel_
+ 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 rendimiento cuando es necesario):
+ sacrificar rendimiento cuando es necesario) [DWCP]_:
Pre y post condiciones
Ejemplo::
}
}
- 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
+ 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()``.
+ programa, antes de que la función ``main()`` [DWUT]_.
Ejemplo::
}
Orden de construcción estática
- a diferencia de C++, D_ garantiza el orden de inicialización de los
+ 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.
+ los módulos [DWMO]_.
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.
+ Todas las variables son inicializadas por el lenguaje (a menos que el
+ usuario pida explícitamente que no lo sean) [DWTY]_ [DWVI]_. 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::
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
+ 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.
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.
+ ``scope``, que limita la vida de un objeto un bloque de código [DWES]_.
Ejemplo::
} // 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
+ 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.
+ *scope*, ya sea cuando se sale del *scope* normalmente o por una falla
+ [DWES]_.
Ejemplo::
acciones a ejecutar al finalizar el *scope*.
Primitivas de sincronización de hilos
- la programación multi-hilo está directamente soportada por el lenguaje,
+ 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::
+ sincronización [DWSY]_. Por ejemplo::
class Foo {
synchronized void bar() { /* cuerpo */ }
__ 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 como un
-proyecto personal y privado de Tomas Lindquist Olsen, que estuvo trabajando de
-forma privada en el proyecto hasta mediados de 2008, momento en que decide
-publicar el código mediante una licencia libre. Para ese entonces el
-compilador era todavía inestable y faltaban implementar varias cosas, pero el
-estado era lo suficientemente bueno como para captar varios colaboradores muy
-capaces, como `Christian Kamm`_ y Frits Van Bommel que rápidamente se
-convirtieron en parte fundamental del proyecto. El primer *release* (0.9) de
-una versión relativamente completa y estable fue a principios de 2009 que fue
-seguido por la versión 0.9.1 que como puntos más salientes agregó soporte para
-x86-64 y assembly embebido. El compilador tuvo y sigue teniendo 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.
+como *back-end*. Fue un muy buen compilador pero estuvo abandonado por casi
+tres años. A mediados de este año recibió un nuevo impulso y de a poco se está
+poniendo al día con los *front-ends* actuales de DMD_ 1.0 y 2.0, aunque la
+versión 2.0 viene bastante más rezagada y todavía no es una alternativa viable
+a DMD_.
+
+LDC_ sufrió una suerte similar, es un compilador joven que utiliza como
+*back-end* a LLVM_ (una infraestructura modera para construir compiladores),
+nacido a mediados de 2007 como un proyecto personal y privado de Tomas
+Lindquist Olsen, que estuvo trabajando de forma privada en el proyecto hasta
+mediados de 2008, momento en que decide publicar el código mediante una
+licencia libre. Para ese entonces el compilador era todavía inestable
+y faltaban implementar varias cosas, pero el estado era lo suficientemente
+bueno como para captar varios colaboradores muy capaces, como `Christian
+Kamm`_ y Frits Van Bommel que rápidamente se convirtieron en parte fundamental
+del proyecto. El primer *release* (0.9) de una versión relativamente completa
+y estable fue a principios de 2009 que fue seguido por la versión 0.9.1 que
+como puntos más salientes agregó soporte para x86-64 y assembly embebido. El
+compilador tuvo un crecimiento excepcional pero estuvo muy inactivo por algún
+tiempo y, si bien sigue siendo mantenido, en general los nuevos *front-end* de
+DMD_ llevan tiempo de integrar y no está al día con el *back-end* de LLVM_
+(por ejemplo desde que se actualizó para utilizar LLVM_ 2.7 que perdió la
+capacidad de generar símbolos de depuración).
Además de estos compiladores hay varios otros experimentales, pero ninguno de
ellos de calidad suficiente todavía. Por ejemplo hay un compilador
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_.
-
+ser `Software Libre`_ podía ser modificado de ser necesario. Pero finalmente,
+dada la poca confiabilidad que presenta la continuidad del desarrollo de tanto
+GDC_ como LDC_, y que el código de DMD_ está disponible en su totalidad
+(aunque no sea `Software Libre`_ por completo), se optó por utilizar este
+último, dado que es la implementación de referencia que fue más constantemente
+mantenida y desarrollada.
.. include:: links.rst
projects / z.facultad / 75.00 / informe.git / blobdiff