¿Por qué se diseñó de esta manera la sintaxis C para matrices, punteros y funciones?

Después de haber visto (¡y preguntado!) Tantas preguntas similares a

¿Qué int (*f)(int (*a)[5])significa en C?

e incluso viendo que habían hecho un programa para ayudar a las personas a comprender la sintaxis de C, no puedo evitar preguntarme:

¿Por qué se diseñó la sintaxis de C de esta manera?

Por ejemplo, si estuviera diseñando punteros, traduciría "un puntero a una matriz de punteros de 10 elementos" en

int*[10]* p;

y no

int* (*p)[10];

que creo que la mayoría de la gente estaría de acuerdo es mucho menos directo.

Así que me pregunto, ¿por qué la sintaxis no intuitiva? ¿Hubo un problema específico que resuelve la sintaxis (¿tal vez una ambigüedad?) Que desconozco?

Mi comprensión de la historia es que se basa en dos puntos principales ...

En primer lugar, los autores del lenguaje prefirieron hacer la sintaxis centrada en la variable en lugar de centrada en el tipo. Es decir, querían que un programador mirara la declaración y pensara "si escribo la expresión *func(arg), eso dará como resultado int; si escribo *arg[N]tendré un flotante" en lugar de " funcdebe ser un puntero a una función que tome esto y devolviendo eso ".

La entrada C en Wikipedia afirma que:

La idea de Ritchie era declarar identificadores en contextos similares a su uso: "la declaración refleja el uso".

... citando p122 de K & R2 que, por desgracia, no tengo que buscar para encontrar la cotización extendida para usted.

En segundo lugar, es realmente muy difícil encontrar una sintaxis para la declaración que sea consistente cuando se trata de niveles arbitrarios de indirección. Su ejemplo podría funcionar bien para expresar el tipo que pensó de inmediato, pero ¿se adapta a una función que toma un puntero a una serie de esos tipos y devuelve algún otro desastre horrible? (Tal vez lo hace, pero ¿verificó? ¿Puedes probarlo? ).

Recuerde, parte del éxito de C se debe al hecho de que los compiladores se escribieron para muchas plataformas diferentes, por lo que podría haber sido mejor ignorar cierto grado de legibilidad en aras de facilitar la escritura de los compiladores.

Dicho esto, no soy un experto en gramática del lenguaje o redacción de compiladores. Pero sé lo suficiente como para saber que hay mucho que saber;)

Muchas de las rarezas del lenguaje C pueden explicarse por la forma en que funcionaban las computadoras cuando fue diseñado. Había cantidades muy limitadas de memoria de almacenamiento, por lo que era muy importante minimizar el tamaño de los archivos de código fuente . La práctica de programación en los años 70 y 80 consistía en asegurarse de que el código fuente contuviera la menor cantidad posible de caracteres y, preferiblemente, que no hubiera comentarios excesivos sobre el código fuente.

Por supuesto, esto es ridículo hoy en día, con espacio de almacenamiento prácticamente ilimitado en los discos duros. Pero es parte de la razón por la cual C tiene una sintaxis tan extraña en general.

Con respecto a los punteros de matriz específicamente, su segundo ejemplo debería ser int (*p)[10];(sí, la sintaxis es muy confusa). Quizás lo leería como "int puntero a una matriz de diez" ... lo que tiene sentido de alguna manera. Si no fuera por el paréntesis, el compilador lo interpretaría como una matriz de diez punteros, lo que le daría a la declaración un significado completamente diferente.

Dado que los punteros de matriz y los punteros de función tienen una sintaxis bastante oscura en C, lo más sensato es eliminar la rareza. Quizás así:

Ejemplo oscuro:

int func (int (*arr_ptr)[10])
{
  return 0;
}

int main()
{
  int array[10];
  int (*arr_ptr)[10]  = &array;
  int (*func_ptr)(int(*)[10]) = &func;

  func_ptr(arr_ptr);
}

Ejemplo no oscuro, equivalente:

typedef int array_t[10];
typedef int (*funcptr_t)(array_t*);


int func (array_t* arr_ptr)
{
  return 0;
}

int main()
{
  int        array[10];
  array_t*   arr_ptr  = &array; /* non-obscure array pointer */
  funcptr_t  func_ptr = &func;  /* non-obscure function pointer */

  func_ptr(arr_ptr);
}

Las cosas pueden volverse aún más oscuras si se trata de matrices de punteros de función. O el más oscuro de todos: funciones que devuelven punteros de función (ligeramente útiles). Si no usa typedefs para tales cosas, rápidamente se volverá loco.

Es bastante simple: int *psignifica que *pes un int; int a[5]significa que a[i]es un int.

int (*f)(int (*a)[5])

Significa que *fes una función, *aes una matriz de cinco enteros, por lo que fes una función que toma un puntero a una matriz de cinco enteros y devuelve int. Sin embargo, en C no es útil pasar un puntero a una matriz.

Las declaraciones de C rara vez se complican tanto.

Además, puede aclarar usando typedefs:

typedef int vec5[5];
int (*f)(vec5 *a);

Creo que debe considerar * [] como operadores que están unidos a una variable. * se escribe antes de una variable, [] después.

Leamos la expresión de tipo

int* (*p)[10];

El elemento más interno es p, una variable, por lo tanto

p

significa: p es una variable.

Antes de la variable hay un *, el operador * siempre se antepone a la expresión a la que se refiere, por lo tanto,

(*p)

significa: la variable p es un puntero. Sin el () el operador [] a la derecha tendría mayor prioridad, es decir

**p[]

sería analizado como

*(*(p[]))

El siguiente paso es []: como no hay más (), [] tiene mayor prioridad que el exterior *, por lo tanto

(*p)[]

significa: (la variable p es un puntero) a una matriz. Luego tenemos el segundo *:

* (*p)[]

significa: ((la variable p es un puntero) a una matriz) de punteros

Finalmente tiene el operador int (un nombre de tipo), que tiene la precedencia más baja:

int* (*p)[]

significa: (((la variable p es un puntero) a una matriz) de punteros) a entero.

Por lo tanto, todo el sistema se basa en expresiones de tipo con operadores, y cada operador tiene sus propias reglas de precedencia. Esto permite definir tipos muy complejos.

No es tan difícil cuando empiezas a pensar y C nunca fue un lenguaje muy fácil. Y int*[10]* prealmente no es más fácil que int* (*p)[10] Y qué tipo de k estaría enint*[10]* p, k;