-informe.latex
-informe.html
-informe.pdf
+build/
+# Makefile for Sphinx documentation
+#
-rst=rst
-latex=latex
-html=html
+# You can set these variables from the command line.
+SPHINXOPTS =
+SPHINXBUILD = sphinx-build
+PAPER =
-rstopts=--section-subtitles --language=es
-latexopts=--use-latex-footnotes --use-latex-citations --use-latex-docinfo \
- --use-latex-toc --documentclass=book --use-verbatim-when-possible
-printopts=--hyperlink-color=0
-htmlopts=--footnote-references=superscript --cloak-email-addresses
+# Internal variables.
+PAPEROPT_a4 = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS = -d build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
-targets=informe.pdf informe.$(html) #informe-print.pdf
+.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest
-docnames=informe informe-print
+help:
+ @echo "Please use \`make <target>' where <target> is one of"
+ @echo " html to make standalone HTML files"
+ @echo " dirhtml to make HTML files named index.html in directories"
+ @echo " pickle to make pickle files"
+ @echo " json to make JSON files"
+ @echo " htmlhelp to make HTML files and a HTML help project"
+ @echo " qthelp to make HTML files and a qthelp project"
+ @echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+ @echo " changes to make an overview of all changed/added/deprecated items"
+ @echo " linkcheck to check all external links for integrity"
+ @echo " doctest to run all doctests embedded in the documentation (if enabled)"
-all: $(targets) clean-tmp
+clean:
+ -rm -rf build/*
-# Informe
-informe.$(latex): informe.$(rst)
- @echo "Generando $@..."
- @rst2latex $(rstopts) $(latexopts) "$(basename $<).$(rst)" > "$@"
+html:
+ $(SPHINXBUILD) -b html $(ALLSPHINXOPTS) build/html
+ @echo
+ @echo "Build finished. The HTML pages are in build/html."
-informe.$(html): informe.$(rst)
- @echo "Generando $@..."
- @rst2html $(rstopts) $(htmlopts) "$(basename $<).$(rst)" > "$@"
+dirhtml:
+ $(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) build/dirhtml
+ @echo
+ @echo "Build finished. The HTML pages are in build/dirhtml."
-informe.pdf: informe.$(latex)
- @echo "Generando $@..."
- @pdflatex "$(basename $<).$(latex)" > /dev/null
- @pdflatex "$(basename $<).$(latex)" > /dev/null
+pickle:
+ $(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) build/pickle
+ @echo
+ @echo "Build finished; now you can process the pickle files."
-# Informe para imprimir
-informe-print.$(latex): informe.$(rst)
- @echo "Generando $@..."
- @rst2latex $(rstopts) $(latexopts) $(printopts) "$(basename $<).$(rst)" > "$@"
+json:
+ $(SPHINXBUILD) -b json $(ALLSPHINXOPTS) build/json
+ @echo
+ @echo "Build finished; now you can process the JSON files."
-informe-print.pdf: informe-print.$(latex)
- @echo "Generando $@..."
- @pdflatex "$(basename $<).$(latex)" > /dev/null
- @pdflatex "$(basename $<).$(latex)" > /dev/null
+htmlhelp:
+ $(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) build/htmlhelp
+ @echo
+ @echo "Build finished; now you can run HTML Help Workshop with the" \
+ ".hhp project file in build/htmlhelp."
-clean-tmp:
- @$(RM) $(addsuffix .aux, $(docnames)) $(addsuffix .out,$(docnames))
- @$(RM) $(addsuffix .log, $(docnames)) $(addsuffix .toc, $(docnames)) texput.log
- @$(RM) texput.log
+qthelp:
+ $(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) build/qthelp
+ @echo
+ @echo "Build finished; now you can run "qcollectiongenerator" with the" \
+ ".qhcp project file in build/qthelp, like this:"
+ @echo "# qcollectiongenerator build/qthelp/tesis.qhcp"
+ @echo "To view the help file:"
+ @echo "# assistant -collectionFile build/qthelp/tesis.qhc"
-clean: clean-tmp
- @$(RM) -fv $(targets) $(addsuffix .latex, $(docnames))
+latex:
+ $(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) build/latex
+ @echo
+ @echo "Build finished; the LaTeX files are in build/latex."
+ @echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
+ "run these through (pdf)latex."
-.PHONY: clean all
+changes:
+ $(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) build/changes
+ @echo
+ @echo "The overview file is in build/changes."
+linkcheck:
+ $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) build/linkcheck
+ @echo
+ @echo "Link check complete; look for any errors in the above output " \
+ "or in build/linkcheck/output.txt."
+
+doctest:
+ $(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) build/doctest
+ @echo "Testing of doctests in the sources finished, look at the " \
+ "results in build/doctest/output.txt."
+++ /dev/null
-
-==========================
-Recolección de basura en D
-==========================
-
-
------
-Tesis
------
-
-:Autor: Leandro Lucarella (77891)
-:Contacto: llucare@fi.uba.ar
-:Autor: Tutora: Lic. Rosa Wachenchauzer
-:Organización: Departamento de Computación, Facultad de Ingeniería
-:Organización: Universidad de Buenos Aires
-:Fecha: |date|
-:Revisión: 1
-:Estado: Borrador
-
-
-.. contents::
-
-
-.. ===========================================================================
-
-
-Introducción
-============
-.. Presenta el problema y temas a ser tratados en el trabajo.
- ESTADO: TERMINADO
-
-Los lenguajes de programación modernos tienen una tendencia cada vez
-más marcada a adoptar técnicas sofisticadas, haciéndolos más ricos y
-convirtiéndolos realmente en lenguajes, no en meros preprocesadores que
-convierten de una forma muy directa el código en *assembly*, permitiendo
-construcciones semánticamente más ricas y permitiendo al programar una
-mayor expresividad para plasmar algoritmos sin detenerse en los detalles
-del *hardware*.
-
-Estos conceptos supuestamente avanzados provienen, en general, de
-lenguajes académicos (muchos de ellos funcionales) que implementan estas
-funcionalidades hace mucho tiempo, pero que para su época, o bien no
-tuvieron suficiente difusión en el ambiente comercial, o bien eran muy
-lentos por la baja capacidad de procesamiento de la época o incluso
-demasiado *revolucionarios* para ser adoptados por programadores que no
-podían ver las ventajas que esos nuevos conceptos proveen.
-
-El caso de la recolección de basura (*garbage collection* en inglés)
-es uno de los más representativos. Lisp_ introdujo a principio de los
-'60 este concepto, como un mecanismo para alocar y liberar recursos
-(en general memoria alocada en el *heap*) de forma automática. Pero
-no fue hasta avanzados los '90 que esta técnica se empezó a utilizar
-en lenguajes de programación de uso comercial, cuando fue popularizado
-por Java_. Incluso luego de más de 30 años para Java_ era costosa la
-recolección de basura, lo que sumado a la presencia de una máquina
-virtual para ejecutar los programas producidos, condujo a que estos
-lenguajes sean notablemente lentos. Aún así Java_ creció y entre las
-mejoras introducidas hubieron mejoras en la recolección de basura. Otros
-lenguaje de programación populares que utilizan alguna forma de
-recolección de basura son Python_, Ruby_, PHP_ y `C#`_, entre otros.
-
-.. INTRODUCCION ..............................................................
-
-Importancia de la Recolección de Basura
----------------------------------------
-.. Breve descripción de la utilidad de la recolección de basura
- ESTADO: TERMINADO
-
-La recolección de basura es muchas veces vista por sus críticos de
-una forma bastante *naïve*. Muchas veces se argumenta que sólo es
-útil para programadores descuidados o que su necesidad es sólo una
-manifestación de un mal diseño. Si bien estas dos afirmaciones pueden
-ser, en algunos casos, ciertas, es falaz pensar que ese es la única
-ventaja de un recolector de basura. Uno de los aspectos más importantes
-de un recolector de basura es lograr un mayor nivel de abstracción
-[JOLI96]_. En particular, al diseñar o programar bibliotecas, de no
-haber un recolector de basura, **la administración de memoria pasa a ser
-parte de la interfaz de la biblioteca**. Y lo peor de este aspecto es
-que muy pocas veces esto es tenido en cuenta, derivando en bibliotecas
-muy difíciles de usar correctamente sin perder memoria, por no quedar
-bien clara la responsabilidad del manejo de memoria.
-
-Esto se debe a que, como se mencionó anteriormente, el manejo de memoria
-es un *artefacto* proveniente del *hardware*, no un concepto propio
-de los algoritmos a representar y como tal, nos impide desarrollar una
-mayor abstracción.
-
-Muchas veces se aduce también que la recolección de basura impide
-el desarrollo de programas eficientes. Si bien es innegable que la
-recolección de basura impone una carga extra, ésta es, en la mayoría
-de los casos, imperceptible. Incluso algunos algoritmos de recolección
-de basura pueden aumentar la eficiencia en casos determinados, como los
-recolectores que compactan, que pueden minimizar considerablemente la
-cantidad de páginas de memoria referenciadas por el programa, mejorando
-el *hit-ratio* tanto de la memoria virtual como del *cache*. Aún si
-este no fuera el caso, o en casos de sistemas de tiempo real o zonas muy
-críticas en cuanto a la eficiencia, muchas veces es posible suspender
-el recolector de basura en dicho fragmento de código. Es cierto que esto
-rompe un poco con la idea de ganar abstracción, pero es necesario sólo
-en casos donde hay que realizar optimizaciones y las optimizaciones son,
-en general, dependientes de la plataforma (*hardware*) y por lo tanto
-de difícil abstracción.
-
-El recolector de basura debe tener un comportamiento correcto y predecible
-para que sea útil, si el programador no puede confiar en el recolector
-de basura, éste se vuelve más un problema que una solución, porque
-introduce nuevos puntos de falla en los programas, y lo que es peor,
-puntos de falla no controlados por el programador, volviendo mucho más
-difícil la búsqueda de errores.
-
-.. INTRODUCCION ..............................................................
-
-El Lenguaje de Programación D
------------------------------
-.. Breve descripción del lenguaje de programación D
- ESTADO: TERMINADO
-
-D_ es un lenguaje de programación 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 *const-correctness*
-(ya sea como una forma de programación por contratos como para mejorar
-las oportunidades de optimización del compilador, en especial con
-código multi-hilo), reflexión y características para soportar mejor
-programación funcional (como *clausuras* completas) y programación
-genérica.
-
-__ `D 1.0`_
-__ `D 2.0`_
-
-Su creador, `Walter Bright`_, desarrollador principal de Zortech C++,
-uno de los primeros compilador de C++ que compilaba a código nativo,
-dice bien claro como nace el lenguaje, citando en su sitio web:
-
- 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.
-
-Lo que 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.
-
-D_ es un lenguaje de programación con sintaxis tipo C, multiparadigma,
-compilado, con tipado fuerte y estático, con buenas capacidades tanto de
-programación de bajo nivel (*system programming*) como de alto nivel,
-siendo incluso compatible binariamente con C (se puede enlazar código
-objeto C con código objeto D). Y este es tal vez el punto más fuerte
-de D_, brindar lo mejor de los 2 mundos. 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.
-
-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.
-
-.. INTRODUCCION ..............................................................
-
-Objetivo
---------
-.. Objetivo de la tesis
- ESTADO: TERMINADO, EN REVISION
-
-La recolección de basura en D_ es un problema floreciente. Si bien pueden
-considerarse válidos todos los modelos propuestos para recolección de
-basura en C, estos son muy restrictivos y poco eficientes, por lo promiscuo
-que este lenguaje. Por otro lado D_ provee muchas construcciones de alto
-nivel, lo que hace que la necesidad de utilizar construcciones de bajo
-nivel sea muy escasa, por lo tanto brinda un campo importante a explorar en
-cuanto a mejoras para el recolector de basura.
-
-Por lo tanto el objetivo del presente trabajo puede resumirse en los
-siguientes puntos:
-
-- Investigar y analizar la viabilidad de mejoras al recolector de
- basura de D_, tanto mejoras menores dentro de las limitaciones actuales
- del lenguaje (incluyendo pero no limitado a mejoras en el algoritmo
- actual de recolección y soluciones en *espacio de usuario* -como
- biblioteca-), como proponiendo mejoras al lenguaje que permitan la
- implementación recolectores más precisos y eficientes.
-- Elegir un conjunto de las mejores soluciones halladas e implementarlas.
- Las soluciones que necesiten modificaciones en el lenguaje serán
- implementadas modificando el compilador libre de D_ GDC_, que
- también será utilizado como plataforma principal de desarrollo y
- prueba (debido a la disponibilidad completa del código fuente y
- la libertad de usarlo y modificarlo libremente). De todas formas,
- siempre se priorizarán las modificaciones al *frontend* [#frontend]_
- sobre las modificaciones al *backend*, permitiendo así que las mejoras
- puedan ser probadas eventualmente en otros compiladores que utilicen
- el *frontend* publicado por DigitalMars_, como DMD_.
-- Realizar pruebas sobre aplicaciones lo más variadas y reales posible
- sobre todas las soluciones implementadas, de manera de determinar de
- forma fehaciente las ventajas de unas y otras en cuanto a latencia,
- consumo de memoria, consumo de procesador, tiempos de pausa, etc.
-- Presentar las conclusiones obtenidas del análisis y las pruebas
- realizadas, tanto en el ámbito académico de la facultad como a la
- comunidad de D_ (con el objetivo de sumar lo construido en este trabajo
- al lenguaje).
-
-.. [#frontend] El *frontend* es el módulo del compilador que realiza el
- análisis sintáctico y semántico del lenguaje. GDC_ utiliza como
- *frontend* el que provee libremente DigitalMars_.
-.. [#backend] El *backend* es el módulo del compilador que emite
- el código binario (o *assembly*, o el lenguaje que produzca el
- compilador como resultado final). GDC utiliza el *backend* del GCC_
- (*GNU Compiler Collection*), uno de los compiladores más populares.
-
-
-.. INTRODUCCION ..............................................................
-
-Limitaciones
-------------
-.. Cosas que no se pretenden hacer en esta tesis
- ESTADO: TERMINADO, EN REVISION
-
-Dado que el lenguaje de programación D_ puede ser enlazado con código
-objeto C, y por lo tanto interactuar directamente con éste, habrán
-limitaciones en el recolector resultante con respecto a esto. En este
-trabajo se busca lograr un recolector que sea eficiente para casos en donde
-el código que interactúa con C esté bien aislado, por lo que estas
-porciones de código pueden quedar por fuera del recolector de basura o
-necesitar un manejo especial.
-
-De no plantear esta limitación se llegaría indefectiblemente a un recolector
-conservativo como el que está disponible en la actualidad.
-
-.. ===========================================================================
-
-
-Recolección de Basura
-=====================
-.. Introducción a la importancia de la recolección de basura y sus
- principales técnicas, con sus ventajas y desventajas. También se da
- un breve recorrido sobre el estado del arte.
- ESTADO: SIN EMPEZAR
-
-
-.. ===========================================================================
-
-
-El Lenguaje de Programación D
-=============================
-.. 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: SIN EMPEZAR, REVISAR LO HECHO
-
-A continuación se enumeran las principales características de D_,
-agrupadas por unidades funcional o paradigmas que soporta:
-
-.. EL LENGUAJE DE PROGRAMACION D .............................................
-
-Programación Genérica
----------------------
-- Clases y funciones pueden ser parametrizadas.
-- Instanciación implícita de funciones parametrizadas.
-- Especialización parcial y explícita.
-- Acepta tipos, valores y plantillas como parámetros.
-- Acepta cantidad de parámetros variables.
-- Soporta *mixins* [#dmixin]_.
-- ``if`` estático (``static if``) [#dstaticif]_.
-- Inferencia de tipos básica implícita [#dtypeinf]_ y explícita
- (mediante ``typeof``) [#dtypeof]_.
-- Expresiones ``is`` [#difexpr]_.
-- Iteración sobre colecciones (``foreach``).
-
-.. [#dmixin] *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. Más
- información en http://www.digitalmars.com/d/mixin.html
-.. [#dstaticif] Esta construcción 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). Más información
- en http://www.digitalmars.com/d/version.html#staticif
-.. [#dtypeinf] Si no se especifica un tipo al declarar una variable,
- se infiere del tipo de su inicializador. Más información en
- http://www.digitalmars.com/d/declaration.html#AutoDeclaration
-.. [#dtypeof] ``typeof`` permite especificar un tipo
- inferido de una expresión. Más información en
- http://www.digitalmars.com/d/declaration.html#typeof
-.. [#difexpr] Las *expresiones ``if``* 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. Más información en
- http://www.digitalmars.com/d/expression.html#IsExpression
-
-.. EL LENGUAJE DE PROGRAMACION D .............................................
-
-Programación de Bajo Nivel (*system programming*)
--------------------------------------------------
-- Compila a código de máquina nativo (no necesita una máquina virtual).
-- Provee acceso a *assembly* (y por lo tanto, acceso directo al
- *hardware*).
-- ``goto``.
-- Soporta todos los tipos de C.
-- ABI [#abi]_ compatible con C (genera archivos objeto estándar por lo que
- se puede enlazar con código C).
-- Permite manejo de memoria explícito (permitiendo alocar estructuras en
- el *stack* o en el *heap*).
-- Objetos *livianos* (no polimórficos) y arreglos *livianos* (estáticos,
- sin *overhead* como C).
-- La `programación genérica`_ 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.
-- Control de alineación de miembros de una estructura.
-
-.. [#abi] Interfaz de Aplicación Binaria (del inglés *Application Binary
- Interface*).
-
-.. EL LENGUAJE DE PROGRAMACION D .............................................
-
-Programación de Alto Nivel
---------------------------
-- Manejo de memoria automática (recolección de basura).
-- Sistema de módulos (similar a Python_).
-- Funciones y delegados:
-
- - Son ciudadanos de primera clase [#1stclasscity]_.
- - Pueden ser sobrecargados.
- - Pueden estar anidados.
- - Argumentos de entrada/salida.
- - Argumentos por omisión.
- - Evaluación perezosa (*lazy*) de argumentos.
- - Cantidad de argumentos variables (con tipado seguro).
-
-- Arreglos *dinámicos* (de longitud variable) y arreglos asociativos
- (también conocidos como *hashes* o diccionarios) y son ciudadanos
- de primera clase [#1stclasscity]_, soporta rebanado (*array slicing*
- [#dslicing]_) y chequeo de límites (*bound checking*).
-- Soporta *strings* como tipo nativo (con codificación utf-8), incluyendo
- la capacidad de hacer un ``switch`` sobre estos.
-- ``alias`` [#dalias]_.
-- Documentación embebida.
-- Números complejos.
-
-.. [#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.
-.. [#dslicing] Se refiere a la capacidad de referirse a una porción de
- un arreglo. Profundizaremos sobre esta característica más adelante
- porque es importante a la hora de elegir un método de recolección
- de basura.
-.. [#dalias] Análogo al ``typedef`` de C/C++.
-
-.. EL LENGUAJE DE PROGRAMACION D .............................................
-
-Programación Orientada a Objetos
---------------------------------
-- Objetos *pesadas* (polimórficos).
-- Interfaces.
-- Sobrecarga de operadores (con tipos de retorno covariantes [#dcovariant]_).
-- Clases anidadas.
-- Propiedades [#dprop]_.
-
-.. [#dcovariant] Tipo de retorno covariante se refiere a la
- capacidad de 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. Más información en
- http://www.digitalmars.com/d/function.html
-.. [#dprop] En D_ se refiere a funciones miembro que pueden ser tratadas
- sintácticamente como campos de esa clase/estructura. Más información
- en http://www.digitalmars.com/d/property.html#classproperties
-
-.. EL LENGUAJE DE PROGRAMACION D .............................................
-
-Programación Confiable
-----------------------
-- Diseño por contrato [#ddbc]_:
-
- - Precondiciones.
- - Postcondiciones.
- - Invariantes de representación.
- - Afirmaciones (*asserts*).
-
-- Pruebas unitarias.
-- Orden de construcción estática (inicialización de módulos) determinado.
-- Inicialización garantizada.
-- RAII [#draii]_ (*Resource adquisition is initialization*).
-- Guardias de contexto (*scope guards*).
-- Excepciones (con ``try``, ``catch`` y ``finally``).
-- Primitivas de sincronización de hilos (``synchronized``).
-
-.. [#ddbc] El diseño por contrato es un concepto creado por Eiffel_ a
- mediados/finales de los '80. Más información sobre el soporte de D_ en
- http://www.digitalmars.com/d/dbc.html
-.. [#draii] 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]_.
-
-
-.. ===========================================================================
-
-
-Definición del Problema
-=======================
-.. Describe más detalladamente los problemas actuales del recolector de
- basura de D, sentando las bases para el análisis de los requerimientos
- de recolección de basura en dicho lenguaje (se explica por qué las
- particularidades descriptas en la sección anterior complican la
- recolección de basura).
- ESTADO: SIN EMPEZAR, REVISAR LO HECHO
-
-Como se ha visto, D_ es un lenguaje de programación muy completo,
-pero aún tiene algunos aspectos inconclusos. Su recolector de basura
-está en un estado de evolución muy temprana. Se trata de un marcado y
-barrido (*mark and sweep*) conservativo que, en ciertas circunstancias,
-no se comporta como es debido, ya que revisa toda la memoria del programa
-en busca de referencias a objetos en el *heap* (en vez de revisar sólo
-las partes que almacenan punteros). Esto produce que, en ciertos casos,
-por ejemplo al almacenar arreglos de número o *strings* en la pila, el
-recolector de basura se encuentre con *falsos positivos*, pensando que
-un área del *heap* está siendo utilizada cuando en realidad el puntero
-que hacía referencia a ésta no era tal. Este efecto puede llevar a la
-pérdida de memoria masiva, llegando al límite de que eventualmente
-el sistema operativo tenga que matar al programa por falta de memoria
-[DNG46407]_. Aún cuando el programa no tenga estos problemas de por sí,
-por usar datos que no pueden ser confundidos con direcciones de memoria,
-este problema podría ser explotado por ataques de seguridad, inyectando
-valores que sí sean punteros válidos y provocando el efecto antes
-mencionado que deriva en la terminación abrupta del programa [DNG35364]_.
-Finalmente, a estos problemas se suman los problemas de *performance*
-[DNG43991]_.
-
-Es difícil que D_ pueda ser un lenguaje de programación exitoso si
-no provee un recolector de basura eficiente y que realmente evite la
-pérdida masiva de memoria. Por otro lado, D_ podría atraer a una base de
-usuarios mucho más amplia, si la gama de estrategias de recolección es
-más amplia, pudiendo lograr adaptarse a más casos de uso sin llegar al
-límite de tener que caer en el manejo explícito de memoria y perder por
-completo las ventajas de la recolección de basura (con la consecuencia
-ya mencionada de que el manejo de memoria tenga que pasar a ser parte
-de las interfaces y la complejidad que esto agrega al diseño -y uso-
-de una biblioteca).
-
-
-.. ===========================================================================
-
-
-Análisis de la Solución
-=======================
-.. Describe los resultados del análisis y explica los fundamentos para
- elegir los algoritmos seleccionados para implementar, en base a los
- requerimientos hallados anteriormente.
- ESTADO: SIN EMPEZAR, REVISAR LO HECHO
-
-.. ANALISIS DE LA SOLUCION ...................................................
-
-Soluciones Propuestas
----------------------
-Para poder implementar un recolector de basura no conservativo es
-necesario disponer de un soporte de reflexión (en tiempo de compilación
-[DNG44607]_ y de ejecución [DNG29291]_) bastante completo . De otra forma
-es imposible distinguir si un área de memoria de la pila es utilizada
-como un puntero o como un simple conjunto de datos. D_ provee algún
-grado de reflexión, pero muy limitado como para poder obtener este
-tipo de información. Ya hay un plan para agregar mayores capacidades
-de reflexibilidad [DNG6842]_, y un pequeño avance en este sentido en la
-`versión 1.001`_, pero con algunos problemas [DNG6890]_ [DNG6893]_.
-
-.. _`versión 1.001`: http://www.digitalmars.com/d/changelog.html#new1_001
-
-Se han propuesto otros métodos e implementaciones de recolector de
-basura, por ejemplo colectores con movimiento (*moving collectors*)
-[DNG42557]_ y conteo de referencias [DNG38689]_. Pero D_ es un
-lenguaje muy particular en cuanto a la recolección de basura (al
-permitir `programación de bajo nivel (system programming)`_ hay muchas
-consideraciones a las que otros lenguajes no deben enfrentarse) y no es
-sencillo pensar en otras implementaciones sin hacer modificaciones de
-base al lenguaje.
-
-.. ANALISIS DE LA SOLUCION ...................................................
-
-Problemas para Implementar Colectores con Movimiento
-----------------------------------------------------
-El principal problema es la capacidad de D_ de manipular punteros y
-otras estructuras de bajo nivel, como uniones. O incluso la capacidad
-de interactuar con C. Al mover un objeto de un área de memoria a otro,
-es necesario actualizar todos los punteros que apuntan a éste. En D_
-esta tarea no es trivial [DNG42564]_
-
-.. ANALISIS DE LA SOLUCION ...................................................
-
-Problemas para Implementar Conteo de Referencias
-------------------------------------------------
-Este tipo de recolectores reparten la carga de la recolección de forma
-uniforme a lo largo (y a la par) de la ejecución del programa. El
-problema principal para implementar este tipo de recolección es
-la necesidad de soporte en el compilador (cada asignación debe ser
-acompañada por el incremento/decremento de contadores de referencia), a
-menos que se implemente en una biblioteca. Por otro lado, características
-como el rebanado de arreglos (ver `Programación de Alto Nivel`_) son
-difíciles de proveer con el conteo de referencias, entre otros problemas
-[DNG38704]_.
-
-
-.. ===========================================================================
-
-
-Implementación de la solución:
-==============================
-.. Describe el diseño e implementación de los algoritmos
- seleccionados. Se detalla si la solución se implementa como
- biblioteca o si fue necesario modificar el compilador y de ser así
- si se modificó el *frontend* o el GDC y se comentan problemas y
- limitaciones encontradas.
- ESTADO: SIN EMPEZAR
-
-
-.. ===========================================================================
-
-
-Conclusiones
-============
-.. Se presentan las conclusiones del trabajo, comparando los resultados
- obtenidos con el punto de partida. Se mencionan puntos pendientes o
- nuevas líneas de investigación.
- ESTADO: SIN EMPEZAR
-
-
-
-
-.. ===========================================================================
-.. ============================ FIN DEL DOCUMENTO ============================
-.. ===========================================================================
-
-
-.. Pone links "offline" (para generar PDF para imprimir).
-.. .. target-notes::
-
-
-.. Links:
-.. _Lisp: http://www.lisp.org/
-.. _Java: http://www.java.com/
-.. _Python: http://www.python.org/
-.. _Ruby: http://www.ruby-lang.org/
-.. _PHP: http://www.php.net/
-.. _`C#`: http://www.ecma-international.org/publications/standards/Ecma-334.htm
-.. _Eiffel: http://www.eiffel.com/
-.. _D: http://www.digitalmars.com/d/
-.. _`D 1.0`: http://www.digitalmars.com/d/1.0/changelog.html
-.. _`D 2.0`: http://www.digitalmars.com/d/2.0/changelog.html
-.. _`Walter Bright`: http://www.walterbright.com/
-.. _GDC: http://dgcc.sourceforge.net/
-.. _DigitalMars: http://www.digitalmars.com/
-.. _DMD: http://www.digitalmars.com/d/2.0/dcompiler.html
-.. _GCC: http://gcc.gnu.org/
-
-
-.. Macros:
-.. |date| date:: %e de %B de %Y
-
-
-.. Citas:
-.. [JOLI96] Richard Jones, Rafael D Lins. Garbage Collection: Algorithms
- for Automatic Dynamic Memory Management. John Wiley & Sons, 1996.
- ISBN 0-471-94148-4.
-.. [SUTT99] Herb Sutter. Exceptional C++: 47 Engineering Puzzles,
- Programming Problems, and Solutions, 1ra edición. Addison-Wesley
- Professional, 1999. ISBN 0-201-61562-2.
-.. [DNG46407] Oskar Linde. The problem with the D GC. Grupo de noticias
- digitalmars.D, 8 de enero de 2007. `Mensaje número 46407`_.
-.. _`Mensaje número 46407`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=46407
-.. [DNG43991] Andrey Khropov. [Performance] shootout.binarytrees when
- implemented with gc is 10x slower than C# on .NET 2.0. Grupo de noticias
- digitalmars.D, 11 de noviembre de 2006. `Mensaje número 43991`_.
-.. _`Mensaje número 43991`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=43991
-.. [DNG35364] Frank Benoit. GC implementation. Grupo de noticias
- digitalmars.D, 18 de marzo de 2006. `Mensaje número 35364`_.
-.. _`Mensaje número 35364`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=35364
-.. [DNG44607] Russ Lewis. A TODO for somebody: Full Reflection Gets You
- Smarter GC. Grupo de noticias digitalmars.D, 20 de noviembre de
- 2006. `Mensaje número 44607`_.
-.. _`Mensaje número 44607`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=44607
-.. [DNG29291] Larry Evans. How does RTTI help gc?. Grupo de noticias
- digitalmars.D, 21 de octubre de 2005. `Mensaje número 29291`_.
-.. _`Mensaje número 29291`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=29291
-.. [DNG6842] Walter Bright. Transitioning to a type aware Garbage
- Collector. Grupo de noticias digitalmars.D.announce, 22 de enero de
- 2007. `Mensaje número 6842`_.
-.. _`Mensaje número 6842`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6842
-.. [DNG42557] Lionello Lunesu. Is a moving GC really needed?. Grupo de
- noticias digitalmars.D, 2 de octubre de 2006. `Mensaje número 42557`_.
-.. _`Mensaje número 42557`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42557
-.. [DNG38689] Frank Benoit. GC, the simple solution. Grupo de noticias
- digitalmars.D, 4 de junio de 2006. `Mensaje número 38689`_.
-.. _`Mensaje número 38689`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=38689
-.. [DNG42564] xs0. Re: Is a moving GC really needed?. Grupo de noticias
- digitalmars.D, 2 de octubre de 2006. `Mensaje número 42564`_.
-.. _`Mensaje número 42564`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42564
-.. [DNG38704] Walter Bright. Re: GC, the simple solution. Grupo de
- noticias digitalmars.D, 4 de junio de 2006. `Mensaje número 38704`_.
-.. _`Mensaje número 38704`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=38704
-.. [DNG6890] Lionello Lunesu. std.string.split is broken :( (Re: DMD 1.001
- release). Grupo de noticias digitalmars.D.announce, 24 de enero de
- 2007. `Mensaje número 6890`_.
-.. _`Mensaje número 6890`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6890
-.. [DNG6893] Oskar Linde. Re: DMD 1.001 release. Grupo de noticias
- digitalmars.D.announce, 24 de enero de 2007. `Mensaje número 6893`_.
-.. _`Mensaje número 6893`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6893
-.. [HDH03] Martin Hirzel, Amer Diwan, and Matthew Hertz, Proceedings
- of the 18th Conference on Object-Oriented Programming, Systems,
- Languages, and Applications (OOPSLA 2003), Anaheim, CA, Oct. 26-30,
- 2003.
-.. [LINS05] Rafael D Lins. A New Multi-Processor Architecture for
- Parallel Lazy Cyclic Reference Counting. Proceedings of the 17th
- International Symposium on Computer Architecture on High Performance
- Computing - Volume 00 (páginas 35-43), 2005.
-
-.. vim: set ts=2 sts=2 sw=2 et tw=75 :
--- /dev/null
+
+.. Se presentan las conclusiones del trabajo, comparando los resultados
+ obtenidos con el punto de partida. Se mencionan puntos pendientes o
+ nuevas líneas de investigación.
+ ESTADO: SIN EMPEZAR
+
+
+.. _ref_conclusion:
+
+Conclusión
+============================================================================
+
+TODO
+
+
+
+Trabajos relacionados
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Trabajos futuros
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+.. vim: set ts=2 sts=2 sw=2 et tw=75 :
--- /dev/null
+# -*- coding: utf-8 -*-
+#
+# tesis documentation build configuration file, created by
+# sphinx-quickstart on Thu May 7 21:24:51 2009.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# Note that not all possible configuration values are present in this
+# autogenerated file.
+#
+# All configuration values have a default; values that are commented out
+# serve to show the default.
+
+import sys, os
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#sys.path.append(os.path.abspath('.'))
+
+# -- General configuration -----------------------------------------------------
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+extensions = []
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['.templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The encoding of source files.
+#source_encoding = 'utf-8'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General information about the project.
+project = u'tesis'
+copyright = u'2009, Leandro Lucarella'
+
+# The version info for the project you're documenting, acts as replacement for
+# |version| and |release|, also used in various other places throughout the
+# built documents.
+#
+# The short X.Y version.
+version = '1.0'
+# The full version, including alpha/beta/rc tags.
+release = '1.0'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+language = 'es'
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+today_fmt = '%B de %Y'
+
+# List of documents that shouldn't be included in the build.
+#unused_docs = []
+
+# List of directories, relative to source directory, that shouldn't be searched
+# for source files.
+exclude_trees = []
+
+# The reST default role (used for this markup: `text`) to use for all documents.
+#default_role = None
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+# A list of ignored prefixes for module index sorting.
+#modindex_common_prefix = []
+
+
+# -- Options for HTML output ---------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages. Major themes that come with
+# Sphinx are currently 'default' and 'sphinxdoc'.
+html_theme = 'default'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further. For a list of options available for each theme, see the
+# documentation.
+#html_theme_options = {}
+
+# Add any paths that contain custom themes here, relative to this directory.
+#html_theme_path = []
+
+# The name for this set of Sphinx documents. If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# A shorter title for the navigation bar. Default is the same as html_title.
+#html_short_title = None
+
+# The name of an image file (relative to this directory) to place at the top
+# of the sidebar.
+#html_logo = None
+
+# The name of an image file (within the static path) to use as favicon of the
+# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
+# pixels large.
+#html_favicon = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['.static']
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+#html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_use_modindex = True
+
+# If false, no index is generated.
+#html_use_index = True
+
+# If true, the index is split into individual pages for each letter.
+#html_split_index = False
+
+# If true, links to the reST sources are added to the pages.
+#html_show_sourcelink = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it. The value of this option must be the
+# base URL from which the finished HTML is served.
+#html_use_opensearch = ''
+
+# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
+#html_file_suffix = ''
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'tesisdoc'
+
+
+# -- Options for LaTeX output --------------------------------------------------
+
+# The paper size ('letter' or 'a4').
+latex_paper_size = 'a4'
+
+# The font size ('10pt', '11pt' or '12pt').
+latex_font_size = '10pt'
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, documentclass [howto/manual]).
+latex_documents = [
+ ('index', 'tesis.tex', u'Recolección de basura en D',
+ u'Leandro Lucarella', 'manual'),
+]
+
+# The name of an image file (relative to this directory) to place at the top of
+# the title page.
+latex_logo = 'fiuba.png'
+
+# For "manual" documents, if this is true, then toplevel headings are parts,
+# not chapters.
+#latex_use_parts = False
+
+# Additional stuff for the LaTeX preamble.
+latex_preamble = '\setcounter{tocdepth}{3}'
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+latex_use_modindex = False
+
--- /dev/null
+
+.. 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)``.
+
+ 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
+
+
+.. [#abi] Interfaz de Aplicación Binaria (del inglés *Application Binary
+ Interface*).
+
+
+.. _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.
+
+ 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
+
+.. [#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.
+
+
+
+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]_.
+
+ 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]_).
+
+ ``stringof``:
+ representación textual del tipo (ejemplo: ``(1+2).stringof`` -> ``"1
+ + 2"``).
+
+ ``mangleof``:
+ representación textual del tipo *mutilado* [#dmangle]_.
+
+ ``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
+
+
+.. [#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.
+.. [#dnan] Del inglés *Not A Number*, es un valor especial que indica que
+ estamos ante un valor inválido.
+.. [#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.
+
+
+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):
+
+ ure 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.
+
+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_.
+
+
+.. [#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.
+
+
+.. include:: links.rst
+
+.. vim: set ts=2 sts=2 sw=2 et tw=75 :
--- /dev/null
+
+.. Describe más detalladamente los problemas actuales del recolector de
+ basura de D, sentando las bases para el análisis de los requerimientos
+ de recolección de basura en dicho lenguaje (se explica por qué las
+ particularidades descriptas en la sección anterior complican la
+ recolección de basura y cuales son las que más molestan).
+ ESTADO: SIN EMPEZAR, REVISAR LO HECHO
+
+
+.. _ref_dgc:
+
+Recolección de basura en D
+============================================================================
+
+TODO
+
+
+
+Dificultades para recolectar basura en D
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Recolector de basura actual de D
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Diseño
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. Acá iría básicamente lo que escribí en el blog sobre la implmentación
+ actual
+
+TODO
+
+
+
+Implementación
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. Acá diría por qué hay que reescribirlo para usar lo que está
+
+TODO
+
+
+
+Problemas y limitaciones
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+
+
+
+Como se ha visto, D_ es un lenguaje de programación muy completo,
+pero aún tiene algunos aspectos inconclusos. Su recolector de basura
+está en un estado de evolución muy temprana. Se trata de un marcado y
+barrido (*mark and sweep*) conservativo que, en ciertas circunstancias,
+no se comporta como es debido, ya que revisa toda la memoria del programa
+en busca de referencias a objetos en el *heap* (en vez de revisar sólo
+las partes que almacenan punteros). Esto produce que, en ciertos casos,
+por ejemplo al almacenar arreglos de número o *strings* en la pila, el
+recolector de basura se encuentre con *falsos positivos*, pensando que
+un área del *heap* está siendo utilizada cuando en realidad el puntero
+que hacía referencia a ésta no era tal. Este efecto puede llevar a la
+pérdida de memoria masiva, llegando al límite de que eventualmente
+el sistema operativo tenga que matar al programa por falta de memoria
+[DNG46407]_. Aún cuando el programa no tenga estos problemas de por sí,
+por usar datos que no pueden ser confundidos con direcciones de memoria,
+este problema podría ser explotado por ataques de seguridad, inyectando
+valores que sí sean punteros válidos y provocando el efecto antes
+mencionado que deriva en la terminación abrupta del programa [DNG35364]_.
+Finalmente, a estos problemas se suman los problemas de *performance*
+[DNG43991]_.
+
+Es difícil que D_ pueda ser un lenguaje de programación exitoso si
+no provee un recolector de basura eficiente y que realmente evite la
+pérdida masiva de memoria. Por otro lado, D_ podría atraer a una base de
+usuarios mucho más amplia, si la gama de estrategias de recolección es
+más amplia, pudiendo lograr adaptarse a más casos de uso sin llegar al
+límite de tener que caer en el manejo explícito de memoria y perder por
+completo las ventajas de la recolección de basura (con la consecuencia
+ya mencionada de que el manejo de memoria tenga que pasar a ser parte
+de las interfaces y la complejidad que esto agrega al diseño -y uso-
+de una biblioteca).
+
+
+
+Soluciones Propuestas
+
+Para poder implementar un recolector de basura no conservativo es
+necesario disponer de un soporte de reflexión (en tiempo de compilación
+[DNG44607]_ y de ejecución [DNG29291]_) bastante completo . De otra forma
+es imposible distinguir si un área de memoria de la pila es utilizada
+como un puntero o como un simple conjunto de datos. D_ provee algún
+grado de reflexión, pero muy limitado como para poder obtener este
+tipo de información. Ya hay un plan para agregar mayores capacidades
+de reflexibilidad [DNG6842]_, y un pequeño avance en este sentido en la
+`versión 1.001`_, pero con algunos problemas [DNG6890]_ [DNG6893]_.
+
+.. _`versión 1.001`: http://www.digitalmars.com/d/changelog.html#new1_001
+
+Se han propuesto otros métodos e implementaciones de recolector de basura,
+por ejemplo colectores con movimiento (*moving collectors*) [DNG42557]_
+y conteo de referencias [DNG38689]_. Pero D_ es un lenguaje muy particular
+en cuanto a la recolección de basura (al permitir :ref:d_low_level hay
+muchas consideraciones a las que otros lenguajes no deben enfrentarse) y no
+es sencillo pensar en otras implementaciones sin hacer modificaciones de
+base al lenguaje.
+
+
+
+Problemas para Implementar Colectores con Movimiento
+
+El principal problema es la capacidad de D_ de manipular punteros y
+otras estructuras de bajo nivel, como uniones. O incluso la capacidad
+de interactuar con C. Al mover un objeto de un área de memoria a otro,
+es necesario actualizar todos los punteros que apuntan a éste. En D_
+esta tarea no es trivial [DNG42564]_
+
+
+
+Problemas para Implementar Conteo de Referencias
+
+Este tipo de recolectores reparten la carga de la recolección de forma
+uniforme a lo largo (y a la par) de la ejecución del programa. El
+problema principal para implementar este tipo de recolección es
+la necesidad de soporte en el compilador (cada asignación debe ser
+acompañada por el incremento/decremento de contadores de referencia), a
+menos que se implemente en una biblioteca. Por otro lado, características
+como el rebanado de arreglos (ver :ref:d_high_level) son
+difíciles de proveer con el conteo de referencias, entre otros problemas
+[DNG38704]_.
+
+
+.. include:: links.rst
+
+.. vim: set ts=2 sts=2 sw=2 et tw=75 :
--- /dev/null
+
+.. Introducción a la importancia de la recolección de basura y sus
+ principales técnicas, con sus ventajas y desventajas. También se da
+ un breve recorrido sobre el estado del arte.
+ ESTADO: SIN EMPEZAR
+
+
+.. _ref_gc:
+
+Recolección de basura
+============================================================================
+
+TODO
+
+.. Breve descripción de la utilidad de la recolección de basura
+ ESTADO: TERMINADO
+
+La recolección de basura es muchas veces vista por sus críticos de
+una forma bastante *naïve*. Muchas veces se argumenta que sólo es
+útil para programadores descuidados o que su necesidad es sólo una
+manifestación de un mal diseño. Si bien estas dos afirmaciones pueden
+ser, en algunos casos, ciertas, es falaz pensar que ese es la única
+ventaja de un recolector de basura. Uno de los aspectos más importantes
+de un recolector de basura es lograr un mayor nivel de abstracción
+[JOLI96]_. En particular, al diseñar o programar bibliotecas, de no
+haber un recolector de basura, **la administración de memoria pasa a ser
+parte de la interfaz de la biblioteca**. Y lo peor de este aspecto es
+que muy pocas veces esto es tenido en cuenta, derivando en bibliotecas
+muy difíciles de usar correctamente sin perder memoria, por no quedar
+bien clara la responsabilidad del manejo de memoria.
+
+Esto se debe a que, como se mencionó anteriormente, el manejo de memoria
+es un *artefacto* proveniente del *hardware*, no un concepto propio
+de los algoritmos a representar y como tal, nos impide desarrollar una
+mayor abstracción.
+
+Muchas veces se aduce también que la recolección de basura impide
+el desarrollo de programas eficientes. Si bien es innegable que la
+recolección de basura impone una carga extra, ésta es, en la mayoría
+de los casos, imperceptible. Incluso algunos algoritmos de recolección
+de basura pueden aumentar la eficiencia en casos determinados, como los
+recolectores que compactan, que pueden minimizar considerablemente la
+cantidad de páginas de memoria referenciadas por el programa, mejorando
+el *hit-ratio* tanto de la memoria virtual como del *cache*. Aún si
+este no fuera el caso, o en casos de sistemas de tiempo real o zonas muy
+críticas en cuanto a la eficiencia, muchas veces es posible suspender
+el recolector de basura en dicho fragmento de código. Es cierto que esto
+rompe un poco con la idea de ganar abstracción, pero es necesario sólo
+en casos donde hay que realizar optimizaciones y las optimizaciones son,
+en general, dependientes de la plataforma (*hardware*) y por lo tanto
+de difícil abstracción.
+
+El recolector de basura debe tener un comportamiento correcto y predecible
+para que sea útil, si el programador no puede confiar en el recolector
+de basura, éste se vuelve más un problema que una solución, porque
+introduce nuevos puntos de falla en los programas, y lo que es peor,
+puntos de falla no controlados por el programador, volviendo mucho más
+difícil la búsqueda de errores.
+
+.. Presenta el problema y temas a ser tratados en el trabajo.
+ ESTADO: TERMINADO
+
+Los lenguajes de programación modernos tienen una tendencia cada vez
+más marcada a adoptar técnicas sofisticadas, haciéndolos más ricos y
+convirtiéndolos realmente en lenguajes, no en meros preprocesadores que
+convierten de una forma muy directa el código en *assembly*, permitiendo
+construcciones semánticamente más ricas y permitiendo al programar una
+mayor expresividad para plasmar algoritmos sin detenerse en los detalles
+del *hardware*.
+
+Estos conceptos supuestamente avanzados provienen, en general, de
+lenguajes académicos (muchos de ellos funcionales) que implementan estas
+funcionalidades hace mucho tiempo, pero que para su época, o bien no
+tuvieron suficiente difusión en el ambiente comercial, o bien eran muy
+lentos por la baja capacidad de procesamiento de la época o incluso
+demasiado *revolucionarios* para ser adoptados por programadores que no
+podían ver las ventajas que esos nuevos conceptos proveen.
+
+El caso de la recolección de basura (*garbage collection* en inglés)
+es uno de los más representativos. Lisp_ introdujo a principio de los
+'60 este concepto, como un mecanismo para alocar y liberar recursos
+(en general memoria alocada en el *heap*) de forma automática. Pero
+no fue hasta avanzados los '90 que esta técnica se empezó a utilizar
+en lenguajes de programación de uso comercial, cuando fue popularizado
+por Java_. Incluso luego de más de 30 años para Java_ era costosa la
+recolección de basura, lo que sumado a la presencia de una máquina
+virtual para ejecutar los programas producidos, condujo a que estos
+lenguajes sean notablemente lentos. Aún así Java_ creció y entre las
+mejoras introducidas hubieron mejoras en la recolección de basura. Otros
+lenguaje de programación populares que utilizan alguna forma de
+recolección de basura son Python_, Ruby_, PHP_ y `C#`_, entre otros.
+
+
+
+Introducción
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Algoritmos principales
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Conteo de referencias
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+
+
+Marcado y barrido
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+
+
+Copia/Semi-espacio
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+
+
+Compactado
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+
+
+Estado del arte
+----------------------------------------------------------------------------
+
+.. explicar la cantidad de cosas que hay (que son muchas) y dar algunos
+ ejemplos.
+
+TODO
+
+
+.. include:: links.rst
+
+.. vim: set ts=2 sts=2 sw=2 et tw=75 :
--- /dev/null
+
+.. Recolección de Basura en D
+ Tesis de Ingeniería en Informática
+ Leandro Lucarella (77891) <llucare@fi.uba.ar>
+ Tutora: Lic. Rosa Wachenchauzer
+ Departamento de Computación, Facultad de Ingeniería
+ Universidad de Buenos Aires
+
+
+.. Usar syntax highlight de D por omisión
+.. highlight:: d
+
+
+.. toctree::
+ :hidden:
+
+ referencias
+ links
+
+
+.. toctree::
+ :maxdepth: 3
+
+ resumen
+ intro
+ d
+ gc
+ dgc
+ viabilidad
+ solucion
+ conclusion
+
+
+.. Pone links "offline" (para generar PDF para imprimir).
+.. target-notes::
+
+
+.. vim: set ts=3 sts=3 sw=3 et tw=75 :
+
--- /dev/null
+
+.. Introducción al trabajo, objetivos, alcance, limitaciones y organización
+ del documento.
+ ESTADO: TERMINADO
+
+
+.. _ref_intro:
+
+Introducción
+============================================================================
+
+La recolección de basura es una técnica que data de fines de los años '50,
+cuando `John McCarthy`_, creador de Lisp_, agregó a dicho lenguaje la
+capacidad de administrar la memoria automáticamente (utilizando conteo de
+referencias), entre muchos otros conceptos revolucionarios para la época
+que recién fueron explotados masivamente en lenguajes dinámicos más
+modernos como Perl_, Python_, Ruby_, etc. A partir de este momento, muchos
+lenguajes tomaron esta característica y hubo una gran cantidad de
+investigación al respecto, tomando particular importancia.
+
+Nuevos algoritmos fueron desarrollados para atacar distintos problemas
+particulares y para mejorar la *performance*, que ha sido una inquietud
+incesante en la investigación de recolectores de basura. Sin embargo el
+lenguaje más masivo que ha adoptado un recolector de basura (al menos en el
+ámbito empresarial) fue Java_, con el cual la investigación sobre
+recolección de basura tomó un impulso extra. Probablemente el mayor
+desarrollo e investigación en cuanto a recolección de basura se siga dando
+para Java_, acotando tal vez un poco el alcance de estos avances dado que
+ese lenguaje tiene características muy particulares (*tipado* estático, corre
+sobre una máquina virtual muy rica en cuanto a información de tipos, etc.)
+no disponibles en otros lenguajes. Sin embargo los lenguajes funcionales
+y con *tipado* dinámico siguieron teniendo un nivel de investigación
+y desarrollo importante, dado que fueron concebidos en su mayoría con la
+recolección de basura como parte del diseño.
+
+Probablemente los lenguajes en los cuales es más difícil aplicar los
+avances que se desprendieron de Java_ o de las otras categoría de lenguajes
+con más avances en recolección de basura sean los de más bajo nivel (como
+C y C++), en los cuales se da lo inverso en cuanto a disponibilidad de
+información en tiempo de ejecución, sumado a la permisividad de estos
+lenguajes para realizar manipulación de memoria directamente y trabajar
+a muy bajo nivel. De la mano de estos lenguajes apareció otra veta de
+investigación en lo que se denominó recolectores de basura *conservativos*.
+
+Una categoría de lenguaje que ha quedado prácticamente vacante es un
+término intermedio entre los lenguajes de muy alto nivel (como Java_,
+Python_, Haskell_, etc.). El lenguaje de programación D_ está en esta
+categoría y, a pesar de haber sido diseñado con soporte de recolección de
+basura, al ser un lenguaje relativamente nuevo, ha tenido muy poco
+desarrollo en ese área. El lenguaje tiene todas las limitaciones de
+lenguajes de bajo nivel como C y C++ pero esas limitaciones suelen estar
+más aisladas, y provee un poco más de información que puede ser aprovechada
+por un recolector de la que suelen proveer los demás lenguajes de estas
+características. Esto presenta una oportunidad única en cuanto
+a investigación y desarrollo de recolectores que se ajusten a estas
+características.
+
+
+
+Objetivo
+----------------------------------------------------------------------------
+
+El objetivos de esta tesis es mejorar el recolector de basura de el
+lenguaje D_, investigando el estado del arte en recolección de basura
+y haciendo un análisis de viabilidad de los algoritmos principales para
+optar por el que mejor se ajuste a D_. Una parte muy importante de este
+análisis es participar de la comunidad del lenguaje y sus diseñadores para
+poder desarrollar una mejora que sea aceptada y pueda ser utilizada por el
+lenguaje. Por lo tanto el algoritmo o mejora que "mejor se ajuste a D_"
+estará supeditado en gran parte a los requerimientos más urgentes de los
+usuarios de D_.
+
+
+
+Alcance
+----------------------------------------------------------------------------
+
+El alcance de este trabajo se limita a los siguientes puntos:
+
+* Explorar los problemas del recolector de basura actual.
+* Evaluar cuales de estos problemas son de mayor importancia para la
+ comunidad de usuarios de D_.
+* Analizar la viabilidad de algoritmos y optimizaciones para solucionar
+ o minimizar el o los problemas de mayor importancia.
+* Implementar una solución o mejora en base al análisis elaborado.
+* Comparar mediante la utilización de un banco de pruebas (*benchmark*) la
+ implementación con la actual y posiblemente con otras implementaciones
+ relevantes a fin de cuantificarla.
+* Proveer todos los elementos necesarios para que la solución pueda ser
+ adoptada por el lenguaje.
+
+
+Limitaciones
+----------------------------------------------------------------------------
+
+Dado que el lenguaje de programación D_ puede ser enlazado con código
+objeto C, y por lo tanto interactuar directamente con éste, podrán haber
+limitaciones en el recolector resultante con respecto a esto. En este
+trabajo se busca lograr un recolector que sea eficiente para casos en donde
+el código que interactúa con C esté bien aislado, por lo que estas
+porciones de código pueden quedar por fuera del recolector de basura
+o necesitar un manejo especial.
+
+
+Organización
+----------------------------------------------------------------------------
+
+Este trabajo se encuentra dividido en 7 cápitos que se describen
+a continuación:
+
+1. :ref:`ref_intro`: breve descripción del problema a tratar, presentando
+ los objetivos y alcances del trabajo.
+2. :ref:`ref_d`: presenta las características principales del lenguaje,
+ destacando aquellas de mayor relevancia para este trabajo.
+3. :ref:`ref_gc`: presenta los algoritmos básicos de recolección de basura
+ y describe el estado del arte.
+4. :ref:`ref_dgc`: explica los problemas particulares que presenta el
+ lenguaje para la recolección de basura, describe el diseño
+ e implementación del recolector actual y presenta sus principales
+ deficiencias.
+5. :ref:`ref_analisis`: realiza un recorrido por los algoritmos presentados
+ en :ref:`ref_gc` analizando su viabilidad para aplicarse en D_.
+6. :ref:`ref_solucion`: propone una solución a los problemas encontrados en
+ :ref:`ref_dgc` en base al análisis hecho en :ref:`ref_analisis`.
+7. :ref:`ref_conclusion`: describe los resultados del trabajo, proponiendo
+ trabajos futuros y relacionados.
+
+
+
+.. include:: links.rst
+
+.. vim: set ts=2 sts=2 sw=2 et tw=75 :
--- /dev/null
+
+.. Lenguajes:
+.. _D: http://www.digitalmars.com/d/
+.. _`D 1.0`: http://www.digitalmars.com/d/1.0/changelog.html
+.. _`D 2.0`: http://www.digitalmars.com/d/2.0/changelog.html
+.. _Lisp: http://www.lisp.org/
+.. _Java: http://www.java.com/
+.. _Python: http://www.python.org/
+.. _Ruby: http://www.ruby-lang.org/
+.. _PHP: http://www.php.net/
+.. _`C#`: http://www.ecma-international.org/publications/standards/Ecma-334.htm
+.. _Eiffel: http://www.eiffel.com/
+.. _Perl: http://www.perl.org/
+.. _Haskell: http://www.haskell.org/
+.. _`.NET`: http://msdn.microsoft.com/netframework/
+
+
+.. Bibliotecas:
+.. _Tango: http://www.dsource.org/projects/tango
+.. _Mango: http://www.dsource.org/projects/mango
+.. _Ares: http://www.dsource.org/projects/ares
+.. _Phobos: http://www.dsource.org/projects/phobos
+.. _DRuntime: http://www.dsource.org/projects/druntime
+
+
+.. Compiladores:
+.. _GDC: http://dgcc.sourceforge.net/
+.. _DMD: http://www.digitalmars.com/d/2.0/dcompiler.html
+.. _GCC: http://gcc.gnu.org/
+.. _DNet: http://dnet.codeplex.com/
+.. _LDC: http://www.dsource.org/projects/ldc
+.. _LLVM: http://llvm.org/
+.. _Dil: http://code.google.com/p/dil/
+
+
+.. Personas:
+.. _`Walter Bright`: http://www.walterbright.com/
+.. _`John McCarthy`: http://en.wikipedia.org/wiki/John_McCarthy_%28computer_scientist%29
+
+
+.. Misc:
+.. _DigitalMars: http://www.digitalmars.com/
+.. _`Software Libre`: http://www.gnu.org/philosophy/free-sw.es.html
+.. _`Learn to Tango with D`: http://www.dsource.org/projects/tango/wiki/LearnToTangoWithD
+
+
+.. Licencias:
+.. _GPL: http://www.gnu.org/copyleft/gpl.html
+.. _Artistic: http://www.artisticlicence.com/
+
+.. vim: set ts=3 sts=3 sw=3 et tw=75 :
--- /dev/null
+
+
+.. _ref_refs:
+
+.. [BKIP08] Kris Macleod Bell, Lars Ivar Igesund, Sean Kelly, and Michael
+ Parker. Learn to Tango with D. Apress, 2007. ISBN 1-59059-960-8.
+
+.. [JOLI96] Richard Jones, Rafael D Lins. Garbage Collection: Algorithms
+ for Automatic Dynamic Memory Management. John Wiley & Sons, 1996.
+ ISBN 0-471-94148-4.
+
+.. [SUTT99] Herb Sutter. Exceptional C++: 47 Engineering Puzzles,
+ Programming Problems, and Solutions, 1ra edición. Addison-Wesley
+
+ Professional, 1999. ISBN 0-201-61562-2.
+.. [DNG46407] Oskar Linde. The problem with the D GC. Grupo de noticias
+ digitalmars.D, 8 de enero de 2007. `Mensaje número 46407`_.
+.. _`Mensaje número 46407`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=46407
+
+.. [DNG43991] Andrey Khropov. [Performance] shootout.binarytrees when
+ implemented with gc is 10x slower than C# on .NET 2.0. Grupo de noticias
+ digitalmars.D, 11 de noviembre de 2006. `Mensaje número 43991`_.
+.. _`Mensaje número 43991`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=43991
+
+.. [DNG35364] Frank Benoit. GC implementation. Grupo de noticias
+ digitalmars.D, 18 de marzo de 2006. `Mensaje número 35364`_.
+.. _`Mensaje número 35364`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=35364
+
+.. [DNG44607] Russ Lewis. A TODO for somebody: Full Reflection Gets You
+ Smarter GC. Grupo de noticias digitalmars.D, 20 de noviembre de
+ 2006. `Mensaje número 44607`_.
+.. _`Mensaje número 44607`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=44607
+
+.. [DNG29291] Larry Evans. How does RTTI help gc?. Grupo de noticias
+ digitalmars.D, 21 de octubre de 2005. `Mensaje número 29291`_.
+.. _`Mensaje número 29291`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=29291
+
+.. [DNG6842] Walter Bright. Transitioning to a type aware Garbage
+ Collector. Grupo de noticias digitalmars.D.announce, 22 de enero de
+ 2007. `Mensaje número 6842`_.
+.. _`Mensaje número 6842`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6842
+
+.. [DNG42557] Lionello Lunesu. Is a moving GC really needed?. Grupo de
+ noticias digitalmars.D, 2 de octubre de 2006. `Mensaje número 42557`_.
+.. _`Mensaje número 42557`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42557
+
+.. [DNG38689] Frank Benoit. GC, the simple solution. Grupo de noticias
+ digitalmars.D, 4 de junio de 2006. `Mensaje número 38689`_.
+.. _`Mensaje número 38689`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=38689
+
+.. [DNG42564] xs0. Re: Is a moving GC really needed?. Grupo de noticias
+ digitalmars.D, 2 de octubre de 2006. `Mensaje número 42564`_.
+.. _`Mensaje número 42564`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42564
+
+.. [DNG38704] Walter Bright. Re: GC, the simple solution. Grupo de
+ noticias digitalmars.D, 4 de junio de 2006. `Mensaje número 38704`_.
+.. _`Mensaje número 38704`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=38704
+
+.. [DNG6890] Lionello Lunesu. std.string.split is broken :( (Re: DMD 1.001
+ release). Grupo de noticias digitalmars.D.announce, 24 de enero de
+ 2007. `Mensaje número 6890`_.
+.. _`Mensaje número 6890`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6890
+
+.. [DNG6893] Oskar Linde. Re: DMD 1.001 release. Grupo de noticias
+ digitalmars.D.announce, 24 de enero de 2007. `Mensaje número 6893`_.
+.. _`Mensaje número 6893`: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=6893
+
+.. [HDH03] Martin Hirzel, Amer Diwan, and Matthew Hertz, Proceedings
+ of the 18th Conference on Object-Oriented Programming, Systems,
+ Languages, and Applications (OOPSLA 2003), Anaheim, CA, Oct. 26-30,
+ 2003.
+
+.. [LINS05] Rafael D Lins. A New Multi-Processor Architecture for
+ Parallel Lazy Cyclic Reference Counting. Proceedings of the 17th
+ International Symposium on Computer Architecture on High Performance
+ Computing - Volume 00 (páginas 35-43), 2005.
+
+
+.. include:: links.rst
+
+.. vim: set ts=3 sts=3 sw=3 et tw=75 :
--- /dev/null
+
+.. Resumen del trabajo
+ ESTADO: TERMINADO
+
+
+.. _ref_resumen:
+
+Resumen
+============================================================================
+
+**RESUMEN**
+
+El problema del manejo de memoria ha sido un factor clave en los lenguajes
+de programación desde que empezaron a forjarse los primero lenguajes con un
+mínimo nivel de abstracción, dado que la administración de memoria
+explícita ha sido un flagelo constante en el mundo de la informática,
+provocando pérdidas de memoria que degradan la eficiencia de programas de
+larga vida y siendo la principal fuente de problemas de seguridad, entre
+otros problemas.
+
+Es por esto que se desde la primera aparición de lenguajes de más alto
+nivel, se buscó abstraer al programador de administrar la memoria
+explícitamente, desarrollando un área de investigación por mérito propio
+denominada **recolección de basura** (o *garbage collection* en inglés). Se
+trata de un servicio provisto (generalmente por el lenguaje) que permite
+auto-detectar cuando una celda de memoria ha dejado de ser utilizada por el
+programa para poder ser reciclada en el futuro, liberando al programador de
+llevar cuenta del tiempo de vida de una celda y su liberación explícita
+cuando ésta deja de utilizarse.
+
+D es un lenguaje de programación multi-paradigma, que soporta programación
+de bajo nivel pero provee construcciones de muy alto nivel también,
+incluyendo un *recolector de basura*. Dadas las amplias y variadas
+características del lenguaje, D propone un nuevo desafío en cuanto al
+diseño de un recolector de basura, y si bien D ya cuenta con un recolector
+que hace lo necesario para funcionar de forma aceptable, su diseño
+e implementación son relativamente sencillas comparadas con el estado del
+arte de la recolección de basura en general.
+
+El objetivo de este trabajo es explorar los problemas del recolector de
+basura actual, evaluar cuales son de mayor importancia para la comunidad,
+analizar la viabilidad de algoritmos y optimizaciones para mejorarlo,
+implementar la solución y proveer todos los elementos necesarios para que
+la solución pueda ser adoptada por el lenguaje. Esto último es de vital
+importancia para este trabajo: la solución tiene que tener buenas
+probabilidades de ser aceptada por la comunidad de D.
+
+
+.. vim: set ts=2 sts=2 sw=2 et tw=75 :
--- /dev/null
+
+.. Acá va lo que decidí hacer en base al análisis anterior y sus razones.
+ ESTADO: SIN EMPEZAR
+
+
+.. _ref_solucion:
+
+Solución adoptada
+============================================================================
+
+TODO
+
+
+
+Recolector naive de referencia
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Set de benchmarks y recolección de estadísticas
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Reescritura del GC actual
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Conversión a "cloning GC"
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Resultados
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+
+.. vim: set ts=2 sts=2 sw=2 et tw=75 :
--- /dev/null
+
+.. Esto sería muy similar a la sección de "Recolección de basura) pero en
+ vez de ir describiendo los algoritmos iría comentando por qué los tomo
+ o descarto
+ ESTADO: SIN EMPEZAR
+
+
+.. _ref_analisis:
+
+Análisis de viabilidad
+============================================================================
+
+
+Conteo de referencias
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Marcado y barrido
+----------------------------------------------------------------------------
+
+TODO
+
+
+
+Con movimiento
+----------------------------------------------------------------------------
+
+TODO
+
+
+.. vim: set ts=2 sts=2 sw=2 et tw=75 :
projects / z.facultad / 75.00 / informe.git / commitdiff
