Apuntadores y arreglos, estructuras, objetos y clases (más bien en C y C++)

 En el principio era la nada.

Luego, a mediados del siglo XIX, se empezó a volver un tema recurrente la idea de construir una máquina de cálculo general, o sea, que pudiera realizar todas las operaciones aritméticas realizables. Esos esfuerzos no conocieron un final feliz hasta mediados del siglo XX cuando surgieron las primeras computadoras electrónicas realmente programables.

Como se expuso en un artículo anterior, la memoria tiene un papel clave en el funcionamiento de estas máquinas, pues es el componente clave donde se almacenan tanto las instrucciones para trabajar, como el resultado del trabajo realizado.

En este artículo, vamos a analizar las abstracciones más frecuentes que se suelen usar para administrar la memoria.

Arreglos.

C / C++

En estos lenguajes un arreglo suele representar un conjunto de valores del mismo tipo que están de alguna manera, y a juicio del programador, relacionados. Internamente, un arreglo indica el inicio de una serie de bloques consecutivos de memoria del mismo tamaño, y cuando hablamos de "tamaño" aquí, nos referimos a bytes. Por ejemplo, en la declaración "int arr[3];" se indica que "arr" es un apuntador al inicio de tres bloques consecutivos de 4 bytes cada uno (por lo general, el tipo con signo "int" suele consumir 4 bytes). Es decir que ese arreglo es el punto de entrada a un bloque de memoria de 12 bytes.

En C y C++ los arreglos son muy rígidos: se espera que el programador tenga una idea clara del tamaño que va a necesitar desde la declaración, no permiten crecimiento o reducción de ese tamaño una vez declarados y para los ojos de programadores más jóvenes que vienen de lenguajes más flexibles son bastante incómodos de manejar. C++, por tanto, integra un tipo conocido como "vector" que permite un manejo más dinámico de los arreglos.

¿Sirve de algo que sean tan estáticos? En casos muy específicos de uso, sí. Pero es probable que la mayor parte del tiempo prefieras usar un vector en lugar de un arreglo.

Así mismo, los arreglos en estos lenguajes permiten algunas expresiones peculiares:

• Dado que un arreglo es en el fondo un apuntador, pueden ser frecuentemente intercambiadas sus sintaxis.
• Si a la posición de un arreglo le agregas o restas un número entero, el compilador va a interpretarlo como un desplazamiento de tamaño de tipo bytes en la memoria.
• ¿Se pueden hacer apuntadores a apuntadores? ¡por supuesto!
  
• ¿Son arreglos de apuntadores? ¡claro! y sus sintaxis siguen siendo de alguna manera intercambiables. Y es en el fondo lo que se hace cuando se hacen arreglos de tipos complejos como estructuras u objetos (C++).
• Una cadena de caracteres es en realidad un arreglo de n+1 posiciones (tantas como sean necesarias) de tipo char y en el byte extra se suele guardar 0x00
• Por lo anterior, una cadena de caracteres se puede navegar usando un ciclo "for" para ir avanzando de posición en posición (o sea, bytes, o letras).
• También por lo anterior, y si no sé el largo específico de una cadena, puedo declararlo como un apuntador de tipo char y pelearme con el tamaño luego.

 Otros lenguajes de tipo estricto.

Otros lenguajes no son tan estrictos con el tamaño de los arreglos, teniendo instrucciones específicas para modificar sus dimensiones, pero siguen siendo estrictos acerca de que todos los elementos que los componen tengan el mismo tipo. Por ejemplo, en Visual Basic se conserva la instrucción "redim" que nos permite cambiar el tamaño de un arreglo, y preservar su información previa.

El manejo de los arreglos, entonces, se vuelve más bien una abstracción de una lista que una relación tan íntima con la memoria como lo podría ser en C y C++, y eso hace que su manejo sea mucho más "natural" en términos humanos.

Sin embargo, en todos los lenguajes se comparte esa jerga común del indicador de posición sobre el arreglo. Algunos con el operador "[n]", otros con "(n)", para indicarnos con un número entero en qué parte de la lista estamos leyendo o escribiendo.

Lenguajes de tipo dinámico.

En este caso el arreglo se confunde ya directamente con la estructura, por que no se exige que todos sus miembros sean del mismo tipo, pudiendo generar estructuras verdaderamente arbóreas de organización. El tipo de gestión que se hace en estos casos se podría representar a un nivel más bajo como un arreglo de apuntadores, sin embargo, la gestión de la memoria será siempre un reto y es por eso que suelen ser más lentos en su funcionamiento.

En un lenguaje de tipo dinámico la estructura carece de sentido ya que su manejo se confunde directamente con el arreglo, y no suelen existir expresiones sintácticas para definir y manipular estructuras, sino que todo se basa en arreglos.

Estructuras.

Fuera de los lenguajes de tipo estricto, las estructuras no suelen tener mucho sentido, como se mencionó anteriormente, sin embargo, en lenguajes más tradicionales suelen ser muy útiles a la hora de generar abstracciones amigables dentro de un contexto de programación y de agrupar diferentes tipos de variables dentro de un mismo campo semántico.

C/C++.

Podemos pensar en las estructuras como una agrupación similar a un registro de una base de datos, que contiene columnas de diferente tipo, pero que toda la información se refiere a una sola entidad. El ejemplo más clásico es pensar que un usuario tiene nombre (arreglo de caracteres), edad (entero), estatura (punto flotante), activo (binario), grupo (caracter), y esa estructura puede llamarse "alumno".

Si necesitamos tener referencias a varios alumnos, pues podemos hacer un arreglo de alumnos y cada posición va a hacer referencia a la posición de memoria donde se almacenan las referencias a los datos de ese alumno.

En general son poco socorridas las estructuras por lo programadores novatos, por que objetivamente hablando, no representan una necesidad funcional y eso hace que terminen haciendo soluciones peculiares como hacer un arreglo de nombres, otro de edades, otro de estaturas, etc. y usar la posición del arreglo para hacer la correlación de los datos de cada alumno. A nivel de funcionalidad ambos pueden ser sinónimos, pero resultaría mucho más simple darle mantenimiento a un código basado en estructuras.

Objetos y clases.

Sin querer entrar a definir todo el paradigma de la programación orientada a objetos en este punto, hay algunas notas que son pertinentes hacer respecto al uso de la memoria y su relación con los apuntadores.

En un sumarísimo resumen podemos definir como "clase" una plantilla de programa que soluciona un problema muy específico. Una clase como tal no suele ser muy útil a no ser que sea expresada en forma de objeto, y a través de interacciones entre objetos solucionará un problema más complejo o abstracto. Y aunque hay sus excepciones, por lo pronto vamos a priorizar el uso de clases a través de sus instancias (objetos).

Internamente, al momento de compilar o interpretar un programa basado en este paradigma, todo el código íntegro de la clase se cargará a la memoria (recordemos que en última instancia cualquier programa es solamente un conjunto de instrucciones expresadas en forma numérica) y cada que se invoque la creación de una nueva instancia se hará una copia de ese código (o casi, como se verá más adelante) a una nueva sección de memoria y se regresará un apuntador al punto donde inicia la memoria donde está alojada esa copia. Mientras más veces invoquemos "new" más veces se va a copiar ese código y más memoria va a consumir el programa. Y aunque hay recolectores de basura y otros mecanismos, hay que tenerlo presente.

El misterioso "this".

Pensemos que el código de ejecución de una clase mida (por decir) 1 KB. Si cada vez que generamos una instancia de esa clase copiamos la totalidad del código de ejecución que la compone, estaremos gastando siempre 1 KB de memoria, más el necesario para almacenar todas las variables públicas y privadas de esa clase. Podemos llegar fácilmente a la conclusión de que quizás no sea necesario gastar ese kilobyte de memoria por cada instancia, ya que su contenido es, al fin y al cabo, inmutable; entonces nos podemos ahorrar esa memoria si solamente generamos un espacio suficiente para almacenar las variables de la instancia y creamos un mecanismo que nos permita hacer referencia a esos espacios particulares.

Bueno, pues lo anterior es lo que se hace con el apuntador a "this", que es nada más que una forma muy simple de decirle a una función dentro de una clase que use el apuntador de instancia para alterar una variable o invocar un procedimiento. El mecanismo de generación de la instancia entonces guardará una variable especial donde esté esa posición de memoria, y los métodos usarán esa referencia como punto clave. ¿confuso? muchísimo: cuando se escribe el código de una clase es fácil perderse y olvidarnos que ese código será usado a través de instancias. Tenerlo en cuenta nos ayuda a sacarle el máximo provecho, y eso implica usar correctamente el contexto estático de las clases.

El contexto estático.

La intencionalidad de la existencia de las clases es que sus instancias puedan tener sus espacios de memoria aislados y se comporten de manera estable a través de las instancias. Sin embargo, a veces es útil poder trabajar fuera del contexto "personalizado" de la instancia, ya sea por que las operaciones a realizar no requieren usar información de instancia, o por que se requiera establecer valores comunes a todas las instancias de la clase. Para eso se inventó el contexto estático.

En pocas palabras, simplemente no podremos usar el apuntador a "this" dentro de una función estática, y eso implica que no vamos a poder acceder a variables de instancia (que son, básicamente, todas las que no fueron declaradas como estáticas).

Lenguajes de tipo estricto.

Manejar instancias de clases en lenguajes de tipo estricto nos permite comparar si dos apuntadores (o sea, variables) hacen referencia al mismo tipo de clase, usualmente a través de "typeof", y también es posible establecer comparadores entre clases. En esto el premio se lo lleva C++ por que nos permite definir (por sobrecarga) incluso los operadores que podemos usar con nuestras clases.

Un dato importante es que si una clase no define comparador explícito, lo más probable es que el intérprete detecte la operación como ilegal, o bien compare las direcciones de memoria de ambos apuntadores, y al ser obligadamente distinta, devuelva siempre falso.

Lenguajes de tipo dinámico.

Suelen ser mucho más permisivos con la comparación entre instancias de objetos, o bien entre instancias y valores. PHP, por ejemplo, suele evaluar como verdadero si el apuntador simplemente hace referencia a algo.

Existe también el operador "typeof", sin embargo, se pueden generar instancias de una super clase llamada simplemente "Object" que, en Javascript, fue muy socorrido antes de que se pudieran declarar explícitamente clases.

Conclusiones.

Sin importar mucho qué contenga el bloque al que se apunta, un apuntador sigue siendo un número entero positivo.