Pourquoi les concepteurs du langage C ont-ils fait l'équivalence des types de cette manière ?

Question

J'apprends le C et je lis sur l'équivalence des types.

Je suis curieux, quelqu'un a-t-il une opinion sur la raison pour laquelle ils ont utilisé l'équivalence structurelle pour les tableaux et les pointeurs mais l'équivalence de déclaration pour les structs et les unions ?

Pourquoi cette disparité ? Quel est l'avantage de faire l'équivalence de déclaration avec les structs/unions et l'équivalence structurelle pour tout le reste ?

Answer 1

Je suis sûr que d'autres présenteront des informations spécifiques au C, mais je mentionnerai que l'équivalence des types est l'un des principaux problèmes classiques de la théorie des langages de programmation. Déterminer si deux types sont réellement équivalents est un problème beaucoup plus délicat qu'il n'y paraît.

Par exemple, voici quelques diapositives de présentation d'un cours universitaire juste pour vous donner un avant-goût du mal de tête.

Answer 2

Je suis sûr que c'était parce que ça semblait être une bonne idée à l'époque.

N'essayez pas de trop penser à la conception du C. Kernighan et Ritchie concevaient un langage d'implémentation de système qui pourrait être bon pour d'autres choses, et se sont retrouvés avec des décisions qu'ils ont regrettées plus tard (la précédence des opérateurs étant la mieux documentée). Certains des problèmes ont été résolus par le comité de normalisation, d'autres étaient trop profondément ancrés.

Comme Uri le souligne dans sa réponse, l'équivalence de type est un problème difficile, et est donc l'un de ceux qui ont probablement été mis de côté par K&R dans le but d'obtenir un compilateur fonctionnel rapidement plutôt qu'une conception propre du langage plus tard.

Answer 3

De bien des façons, c est une expression propre de l'idiome de l'assemblage des années 1970. Sur ces processeurs, les tableaux sont implémentés directement à l'aide de pointeurs, et c copie simplement ce qui suit fait .

Answer 4

L'équivalence structurelle est difficile à vérifier. Les pointeurs et les tableaux sont assez simples, mais les structs et les types union sont plus complexes. La vérification de l'équivalence structurelle est très difficile pour ces types complexes, mais plus facile pour les pointeurs et les tableaux.

EDITAR

A l'origine, j'avais écrit une réponse qui traitait de équivalence de valeur au lieu de équivalence de type, donc ce n'était pas vraiment une réponse à cette question. Mais j'ai reçu quelques votes positifs à son sujet, alors j'ai décidé de le garder ici.

Ce que je sais de l'[équivalence des valeurs], c'est que les pointeurs et les tableaux ont toujours une disposition assez simple en mémoire. Il est donc facile d'effectuer une simple comparaison octet par octet.

Pour les structs et les unions, cette disposition de la mémoire n'est pas nécessairement aussi simple. Vous pouvez, par exemple, avoir une structure avec un int (32 bits) et un double (64 bits). Une telle structure nécessite 128 bits de mémoire, dont 32 ne sont pas réellement pertinents pour la comparaison. La comparaison octet par octet est donc hors de question. L'équivalence de déclaration est donc plus facile à mettre en œuvre.

Answer 5

Ne sous-estimez pas Dennis Ritchie. Chaque langage statiquement typé devrait avoir un moyen de créer un fichier de type type d'abstraction qu'il est impossible pour un utilisateur de falsifier. Pour cela, il faut une construction de type ou une construction de déclaration qui est générative c'est-à-dire que chaque instance de la construction génère un nouveau type, distinct de tout autre. Une telle construction est essentielle si vous voulez éviter que d'autres personnes ne mettent la main sur vos données. (Pour de nombreux exemples, voir le livre de Dave Hanson, intitulé C Interfaces et implémentations .)

Voici donc les valeurs p1 y p2 ont des types différents mais la même représentation :

struct { float x, y } p1;
struct { float x, y } p2;

Pourquoi choisir struct d'être générative ? Parce qu'il est suffisamment général pour permettre un large éventail de représentations pratiques. union est un peu exagéré, mais je soupçonne qu'il s'agit d'une "conception collatérale" ; dans le système de type du C, union se comporte comme une liste struct autant que possible, ce qui simplifie le compilateur.

Soit dit en passant, l'"équivalence de déclaration" est un terme que je n'avais jamais entendu auparavant. Il y a 25 ans, des termes comme "équivalence de nom", "équivalence structurelle" et "équivalence d'occurrence" étaient populaires. Aujourd'hui, les systèmes de types sont beaucoup plus formels, et l'équivalence est généralement définie par des règles logiques plutôt que par un anglais informel. Lorsqu'il est utile de recourir à l'anglais informel, je trouve généralement que l'idée de "générativité" est plus explicative que l'invention d'un nouveau nom pour les règles d'équivalence de chaque nouveau langage.