Hoy en día damos por hecho muchas cosas que han costado muchos años descubrir, usar y pulir. Una de ellas es la gestión de los símbolos. Allá por los años cincuenta, si alguien quería hacer un programa debía escribir el código fuente y, como en estos años los compiladores eran muy simples, directamente te generaban el código ejecutable.
Usualmente el código fuente estaba en tarjetas perforadas y el ejecutable se quedaba en memoria, donde se ejecutaba.
Luego, conforme pasaban los años, los programas se iban haciendo más y más grandes. Recompilar todo cada vez era tedioso y para reutilizar un trozo de código hay que volverlo a escribir. La solución es partir los programas. El problema es que este compilador tan simple no me permite partir los programas.
La solución fue usar dos pasos a la hora de compilar. El primer paso es la compilación a un código intermedio que se denomina código objeto. El código objeto es como el código ejecutable, pero tiene marcas de dónde está cada objeto del código (lo que técnicamente se denomina un símbolo exportado). De ahí el nombre "código objeto". Luego, un segundo paso es el vinculador (o enlazador) que lee esas marcas del código objeto y como si fuera un puzle va componiendo el programa ejecutable final y completo.
Esto causa un problema porque... ¿cómo sabe el código fuente de la parte 1 lo que hay en el código fuente de la parte 2 si puede que incluso hayan sido programados por gente completamente distinta?
PARTE II: SÍMBOLOS Y SÍMBOLOS EXTERNOS
A finales de los sesenta apareción un lenguaje que aún hoy es de los más usados. El lenguaje C. Una de las virtudes del C es que soluciona el problema antes mencionado. La solución que se usa en C es permitir usar objetos sin definirlos. Esto se realiza mediante lo que se denomina la declaración del símbolo. La declaración da toda la información necesaria para usar el símbolo, pero no dice qué es. No lo define.
Lo más usual es declararlos y definirlos que es lo que pongo aquí como ejemplo:
int a=0;
double hipotenusa(double x, double y)
{
return sqrt(x*x+y*y);
}El código objeto generado por este código fuente de ejemplo tiene lo que técnicamente se denomina dos símbolos: El símbolo "a" y el símbolo "hipotenusa". Ambos están definidos, es decir, que hay un trozo de ese código objeto que se asigna al símbolo "a" y otro trozo de ese código objeto que se asigna al símbolo "hipotenusa". El trozo del símbolo "a" está a cero. El trozo del símbolo "hipotenusa" tiene el código ejecutable de la función hipotenusa.
El contenido del código objeto sería algo como
| Símbolo | Objeto asignado |
|---|---|
| a | 0 |
| hipotenusa | {return sqrt(x*x+y*y);} |
Para declarar sin definir los símbolos en C se usa lo siguiente:
extern int a; double hipotenusa(double x, double y);
El código objeto generado por este código fuente de ejemplo tiene dos símbolos: "a" e "hipotenusa". Ninguno está definido, es decir, que este código objeto sólo tiene una lista de los símbolos sin asignarle ningún objeto. Los símbolos sin objeto asignado tienen que obtenerse del exterior cuando el vinculador recomponga el puzle. Son los llamados símbolos externos, porque se definen en algún otro lugar externo al código fuente donde los declaramos.
| Símbolo | Objeto asignado |
|---|---|
| a | externo |
| hipotenusa | externo |
PARTE III: USANDO SÍMBOLOS EXTERNOS
Ahora ya sabemos cómo declarar y definir una función en código fuente y cómo usarla desde otro código fuente. Bastará declararla sin definirla.
programa_parte1.c
/* Declaramos y definimos */
void mifuncion(void)
{
puts("Esta función está programa_parte1.c");
}
programa_parte2.c
/* Declaramos pero no definimos (prototipo) */
void mifuncion(void);
void main(void)
{
puts("Esta función está en programa_parte2.c");
mifuncion(); /* Se usa mifuncion() con haberla sólo declarado */
}
Primero compilamos
Según el compilador la extensión del código objeto será .o .obj .coff, etc. Los códigos objetos generados serán algo así como muestran las siguientes tablas.
programa_parte1.obj
| Símbolo | Objeto asignado |
|---|---|
| mifuncion | {puts("Esta función está programa_parte1.c");} |
programa_parte2.obj
| Símbolo | Objeto asignado |
|---|---|
| mifuncion | externo |
| main | { puts("Esta función está en programa_parte2.c"); mifuncion(); } |
Ahora pasamos el vinculador o enlazador.
El vinculador es lo suficientemente inteligente como para ver que el símbolo "mifuncion" está definido en la parte 1 y es un símbolo externo en la parte 2 donde se usa. Entonces, compone ambas partes haciendo que cuando la función main() llame a mifuncion() lo haga correctamente. Finalmente el símbolo "main" es especial y lo usa como punto de entrada del ejecutable.
PARTE IV: LOS FICHEROS DE INCLUSIÓN
Ahora sólo queda un detalle menor. ¿Vamos a tener que repetir
void mifuncion(void);
cada vez que queramos usar la función mifuncion()? ¿Qué pasará si lo que tengo en el código objeto no es una función sino una biblioteca de cincuenta, cien o mil funciones? ¿Voy a tener que escribir todas las que quiera usar una y otra vez en cada fichero fuente que escriba?
La solución es poner todas las declaraciones en un fichero de cabecera (.h del inglés header). E incluir el fichero con tooodas las definiciones. Esto nos ahorra el escribir cada vez todas las definiciones.
Este uso de los ficheros de inclusión es común en lenguajes como el C y el C++.
PARTE V: LOS MÓDULOS
Realmente, usar un fichero de inclusión es una tontería: ¡ya tenemos los símbolos en el código objeto! ¿No podríamos decir en el código fuente "toma los símbolos de este código objeto"? La respuesta es sí. Existen muchos lenguajes que lo hacen. Entre ellos Java y ActionScript3. A esta acción de extraer símbolos de un código objeto y usarlos en otro código fuente se denomina "importar símbolos". Al código objeto que exporta los símbolos de esta manera se le denomina módulo o paquete.
Existen un par de salvedades a este sistema. En primer lugar, el orden de compilación es importante. Debemos compilar los códigos fuentes de manera que cuando usemos un símbolo, el código objeto que lo contiene haya sido generado previamente. Esto significa que no podemos tener ciclos en el uso de referencia aunque algunos sistemas mezclan el compilador y el vinculador en un único paso para permitir estos ciclos. En segundo lugar, es importante cómo llamamos a los ficheros de código objeto y dónde los ubicamos en el sistema de fichero.
Esto último hace que sea necesaria una jerarquía en los nombres de los módulos, usualmente separados por puntos. Así, un símbolo del sistema de módulos de Java se escribe así "java.lang.NullPointerException" y significa algo como en el directorio "java", en el subdirectorio "lang", el fichero "NullPointerException". Este tipo de nombre de símbolos compuestos de varias partes se llaman nombres completamente cualificados.
Es usual en estos sistemas de módulos que cada fichero sólo pueda definir un símbolo. Aquél que coincide con el nombre del fichero. Hay aquí una rigidez. ¿Podríamos separar los nombres de los ficheros de los nombres de los símbolos?
PARTE VI: LOS ESPACIOS DE NOMBRE
Cuando usamos un nombre cualificado como "java.lang.NullPointerException" hemos pensado que "java" es un directorio, pero desde el punto de vista del programador no es más que un nombre que contiene otros nombres, entre ellos "lang". Asimismo "lang" contiene "NullPointerException". Por esta razón, es común llamar a "java" y a "java.lang" un espacio de nombres (namespace en inglés). En el caso de Java (y de AS3) los espacios de nombres están relacionados con los directorios.
Sin embargo, en C# y C++ no es así y pueden definirse espacios de nombres en el código fuente. Eso significa que los códigos objetos exportan los símbolos con sus nombres cualificados y el vinculador tiene que ser un poco más inteligente.
Modifiquemos el programa anterior para incluir un espacio de nombre llamado "miespacio" usando C++ y añadiré otra "mifuncion" en "otroespacio". El C++ es exótico porque usa :: para separar los nombres cualificados en vez del punto.
programa_parte1.cpp
/* Declaramos y definimos */
namespace miespacio
{
void mifuncion(void)
{
puts("Esta función está programa_parte1.c y en miespacio");
}
}
namespace otroespacio
{
void mifuncion(void)
{
puts("Esta función está programa_parte1.c pero en otroespacio");
}
}programa_parte2.c
/* Declaramos pero no definimos (prototipo) dentro de miespacio*/
namespace miespacio { void mifuncion(void); }
void main(void)
{
puts("Esta función está en programa_parte2.c");
miespacio::mifuncion(); /* Se usa miespacio::mifuncion() pero no otroespacio::mifuncion() */
}
Si ahora miramos los códigos objeto encontramos los siguientes símbolos.
programa_parte1.obj
| Símbolo | Objeto asignado |
|---|---|
| miespacio::mifuncion | {puts("Esta función está programa_parte1.c y en miespacio");} |
| otroespacio::mifuncion | {puts("Esta función está programa_parte1.c pero en otroespacio");} |
programa_parte2.obj
| Símbolo | Objeto asignado |
|---|---|
| miespacio::mifuncion | externo |
| main | { puts("Esta función está en programa_parte2.c"); miespacio::mifuncion(); } |
De esta manera no hay relación entre la ubicación del módulo en el sistema de ficheros y los espacios de nombre que contiene. Esto es importante porque ahora podemos mover el módulo de lugar dentro del disco y no hay que modificar el código fuente.
0 comentarios:
Publicar un comentario