const y punteros: leer declaraciones sin equivocarse

Pocas cosas producen más inseguridad que encontrarse una declaración con dos const y un asterisco y no saber cuál de las dos partes es la inmutable. La buena noticia es que no hay que memorizar casos: existe una regla mecánica que descifra cualquier declaración, y una vez la aplicas, la distinción entre puntero a constante y puntero constante deja de ser trivia sintáctica para convertirse en una herramienta de diseño de interfaces.

Leer declaraciones de derecha a izquierda

El algoritmo es simple: parte del identificador y avanza hacia la derecha mientras puedas; cuando ya no puedas, gira hacia la izquierda. Traduce cada símbolo a palabras. El asterisco se lee “puntero a”, los corchetes “array de” y los paréntesis “función que devuelve”.

Aplicado a los cuatro casos que importan en este nivel:

int        *p;   // p es puntero a int
const int  *p;   // p es puntero a int constante
int *const  p;   // p es puntero constante a int
const int *const p; // p es puntero constante a int constante

La clave está en de qué lado del asterisco cae el const. Si aparece a la izquierda del asterisco, califica al tipo apuntado. Si aparece a la derecha, califica al puntero en sí. Una forma de recordarlo sin ambigüedad: el const que está pegado al identificador, después del asterisco, es el que congela al puntero.

Conviene además saber que const int *p y int const *p son exactamente lo mismo. La segunda forma, aunque menos común, es más regular: si escribes siempre el calificador a la derecha del tipo, la lectura de derecha a izquierda se vuelve puramente mecánica y no hay excepciones que recordar.

Puntero a constante frente a puntero constante

La diferencia práctica se ve mejor con lo que cada declaración prohíbe.

Traducido a código, el compilador rechaza exactamente lo que cabría esperar:

int x = 1, y = 2;

const int *pa = &x;
// *pa = 99;        // error: el dato es constante a traves de pa
pa = &y;            // valido: el puntero no lo es

int *const pb = &x;
*pb = 99;           // valido: el dato no es constante
// pb = &y;         // error: el puntero es constante

const int *const pc = &x;
// *pc = 99;        // error
// pc  = &y;        // error

flowchart TD
D[Declaracion con const y asterisco] --> Q{Donde esta el const}
Q -->|a la izquierda del asterisco| A[Puntero a constante: el dato no se toca]
Q -->|a la derecha del asterisco| B[Puntero constante: la direccion no cambia]
Q -->|a ambos lados| C[Ni el dato ni la direccion]
style A fill:#a6e3a1,color:#11111b
style B fill:#89b4fa,color:#11111b
style C fill:#f9e2af,color:#11111b

Qué garantiza const y qué no

Aquí es donde muchos programadores construyen una intuición equivocada. const no significa “este dato es inmutable”. Significa “a través de este nombre, prometo no modificarlo”. Es una restricción sobre la vía de acceso, no una propiedad del objeto.

La consecuencia inmediata es que un mismo objeto puede ser accesible simultáneamente por una vía calificada y otra no calificada, y modificarlo por la segunda es perfectamente legal:

int x = 10;
const int *lectura = &x;   // vista de solo lectura
int       *escritura = &x; // vista de escritura

*escritura = 20;
// A traves de lectura veremos 20: el objeto cambio legalmente.

Hay, en cambio, una línea que sí es infranqueable. Si el objeto se definió como const, quitarle el calificador con un cast y escribir a través del resultado es comportamiento indefinido, no una picardía tolerada. El compilador puede haber colocado ese objeto en memoria de solo lectura, o haber propagado su valor como constante en tiempo de compilación.

const int fijo = 5;
int *tramposo = (int *)&fijo;   // el cast compila...
// *tramposo = 7;               // ...pero escribir aqui es UB puro

Merece un aviso el caso de las cadenas literales. En C un literal como "hola" tiene tipo array de char sin calificar, de modo que asignarlo a un char * compila sin queja; pero modificar su contenido es comportamiento indefinido y en la práctica suele provocar una violación de segmento, porque vive en una sección de solo lectura del binario. La disciplina correcta es declarar siempre const char * para apuntar a literales.

const correctness en las APIs

El valor real de const no está en que impida errores tontos dentro de una función, sino en que convierte la firma en un contrato legible. Compara estas dos declaraciones:

size_t longitud(char *s);
size_t longitud(const char *s);

La segunda te dice, sin leer una línea de implementación, que la función no tocará tu cadena. Esa es la razón por la que toda la biblioteca estándar está escrita así: en strcpy, el destino es char * y el origen es const char *, y la firma sola te explica la dirección del flujo de datos.

Hay además una razón mecánica para adoptar el hábito desde el principio: la conversión solo funciona en un sentido. Un int * se convierte implícitamente a const int *, pero no al revés. Por eso una función que olvida el const en un parámetro de solo lectura resulta inutilizable para cualquier llamante que tenga datos constantes, y el problema se propaga hacia arriba obligando a añadir casts o a duplicar funciones.

Esa regla tiene una excepción que sorprende a casi todo el mundo la primera vez: la conversión implícita no se propaga a través de dos niveles de indirección. Un int ** no se convierte a const int **, y el rechazo del compilador es correcto, no una molestia:

int         *p;
int        **pp = &p;
// const int **cpp = pp;    // error, y con razon

const int fijo = 5;
// Si la linea anterior se permitiera, esto seria legal:
//   *cpp = &fijo;          // pone en p la direccion de un const
//   *p   = 99;             // y escribe en un objeto constante

Si esa conversión fuera legal, se podría depositar la dirección de un objeto constante en un puntero no calificado sin un solo cast, y escribir después a través de él. El compilador la prohíbe para cerrar exactamente ese agujero. La forma correcta para el segundo nivel es const int *const *, que sí es aceptada.