Ante todo quiero resaltar que las consideraciones que comentare se aplican a lenguajes de programación fuertemente tipados como C++ y Java donde las variables una vez declaradas sólo pueden almacenar datos de su mismo tipo. Otro es el caso para lenguajes dinámicamente tipados como Python. Finalmente concluiremos porqué es mejor pasar objetos como parámetros por referencia.
La ilusión del procedimiento: el entorno de ejecución protegido:
En todos los lenguajes del tipo del Algol, y en esto incluimos a C, cada procedimiento crea un entorno de ejecuciòn limpio, controlado y protegido. Cada procedimiento tiene su propio y privado almacen de variables. Todas las instrucciones dentro del procedimiento puede acceder estas variables privadas o mejor llamadas locales. Cada procedimiento debe creer que esta ejecutándose sobre este entorno protegido como si fuera un programa que corre en una máquina sin ningún programa más. Pero además y en general el procedimiento recibe datos y retorna datos al procedimiento que lo llamó.
El concepto de procedimiento es la unidad base para los compiladores. En general un programa no es presentado en un solo archivo para ser compilado. Cuando hacemos un programa en C++ por ejemplo, creamos archivos de cabecera .h y archivos de implementación .cpp y cada par es compilado en instantes diferentes. El código compilado de cada par puede ser por ejemplo enlazado en una etapa posterior (linking). El concepto de procedimiento es lo que nos permite a los programadores construir programas no triviales.
Que es un namespace o espacio de nombres?
Aquí escribo una introducción a los “namespaces” (espacios de nombres) y “activation records” (registros de activación) que se ven en C++.
La mayoría de los lenguajes de programación basados en procedimientos como C++ le brindan al programador control sobre que variables puede leer y escribir.
Fortran, uno de los lenguajes más antiguos, definía solo 2 namespaces, un namespace global conformado por las variables globales y un namespace local dentro de cada procedimiento.
En general el manejo de namespaces es mas complejo en lenguajes de programación más recientes, dado que un procedimiento puede llamar a otro procedimiento o incluso a sí mismo (recursividad).
De esta manera un programa puede contener múltiples namespaces. El lenguaje define reglas que determinarán a que variables cada procedimiento puede acceder. Estas reglas se llaman “reglas de ámbito (scoping rules)”.
El lenguaje C tiene reglas de ámbito bastante complejas. Primero, el crea un espacio global de nombres que contiene todos los nombres de los procedimientos así como todos los nombres de las variables globales. Este nivel se llama ámbito a nivel de archivo. Todos los nombre en este nivel están declarados con el atributo “static”, por tanto ellos son visibles a cualquier procedimiento en el archivo.
A su vez cada procedimiento puede crear su propio namespace para definir sus variables y parámetros.
Y que es un “activation record” o registro de activación?
Cada procedimiento al ser ejecutado crea su propio nuevo espacio de nombres (namespace). Dentro de cada procedimiento, el programador puede declarar variables que no son accesibles desde fuera de este. Las variables declaradas tienen un tiempo de vida igual al tiempo de vida del procedimiento.
Para manejar este comportamiento, el compilador separa una región de memoria llamada “registro de activación” o “activation record” (AR), para cada llamada individual a un procedimiento. El AR es creado cuando el procedimiento es llamado, y es liberado (destruido) cuando el control regresa al procedimiento que lo llamo.
Pero el AR necesita también guardar el estado de las variables del procedimiento que lo llamo con la intención de crear la ilusión que el procedimiento se esta ejecutando en una máquina sola. Con este fin, se guardan en el AR el estado de los registros del sistema (para los que les gusta Assembler, eax, bax, los también llamados “archivo de registros” o “register file”) para poder reconstruir luego el estado del procedimiento llamante.
En general un AR tiene las siguientes partes:
1. Parámetros: son los parámetros que el procedimiento que llama le entrega al procedimiento que se va a ejecutar (el AR actual pertenece al procedimiento que se va a ejecutar). En general pueden ser valores que el procedimiento llamante le da al procedimiento llamado para que opere con ellos, pero también pueden ser punteros si el procedimiento llamado recibe parámetros por referencia (caso más común en programación orientada a objetos)
2. Register Save Area (o área de salvado de registros): aquí se guardan los registros del sistema (eax, bax, etc)
3. Return value (o valor de retorno): El procedimiento debe poner aquí el valor que retorna al procedimiento que lo llamó
4. Return address (o dirección de retorno): para poder restablecer al program counter (PC) en la posición donde el procedimiento que llamaba llamó a nuestro procedimiento.
5. Access link (enlace para acceso): es una campo del AR, el cual el compilador usa para referenciar donde estan ubicados los otros campos del AR.
6. Parent access record pointer (puntero al AR del padre): este es un puntero y apunto al registro “access link” del procedimiento llamante o “padre”. Esto permite el anidamiento de procedimientos (esto es lo que ocurre en general en nuestros programas, desde un procedimiento A llamamos a otro procedimiento B y desde ese procedimiento B llamamos a otro procedimiento C, y así sucesivamente)
7. Locales: Aquí se almacen las variables locales del procedimiento y los punteros a las variables dinámicamente creadas. Las variables dinámicamente creadas son aquellas que no conocemos en tiempo de compilación (no sabemos si las usaremos o que tamaño en bytes tendrán al momento de compilar nuestro programa). Las variables dinámicamente creadas son las que creamos con la instrucción malloc en C o con las palabra reservada new en C++.
Las variables dinámicamente creadas tienen sus punteros en el AR pero su estructura de datos con sus valores son dispuestas en la pila (también llamada “heap”) y su contenido es liberado automáticamente cuando el puntero que la apuntaba es liberado explícitamente (por ejemplo con una instrucción “delete” en C++, siempre y cuando no hayan más punteros apuntando a la misma data) o automáticamente mediante un “colector de basura” o “garbage collector” en Java.
Ahora, donde almacenamos todos los “activation records” que vamos creando en nuestro programa? Generalmente los activation records de nuestro programa en un momento determinado de su ejecución se almacenan en el “stack” o “pila” . El procedimiento actualmente en ejecución tiene su AR en el tope de esta pila o “stack”. Cada vez que llamamos un procedimiento ponemos su AR en el tope del “stack”. Este paso de poner su AR puede ser hecho por el procedimiento que lo llamó o por el procedimiento llamado por sí mismo. Con este esquema es fácil deducir que el procedimiento padre de todos tendrá su AR en el fondo del stack.
El stack no debe ser confundido con el “heap”, la cual es utilizada principalmente para almacenar estructuras de datos creadas dinámicamente.
Si observamos ahora de nuevo la estructura del activation record (AR) veremos que se reserva espacio de memoria para cada parámetro que el procedimiento recibe. Si el procedimiento recibe un objeto cuya estructura de datos es compleja como parámetro pasado “por valor” y no “por referencia”, entonces el AR tendrá que crear dentro de él una copia del objecto con todos los datos internos que el objeto tenga. Por eso es que actualmente en programación orientada a objetos los parámetros se pasan por referencia, de modo que ahorramos en tiempo de ejecución (no es necesario copiar los datos del objeto o estructura) y en memoria (solo almacenamos un puntero en el AR). Este es el esquema por defecto en Java, donde los parámetros son pasados por referencia.
Bueno, espero que esta introducción sea de utilidad para todos. Muchos saludos.
