Ce que le type opaque interdit, mot pour mot

/* pile.h */
typedef struct pile_s pile;       /* type OPAQUE */
pile* pile_creer(void);
void  pile_empiler(pile* p, int x);

pile p;                          /* (a) */
pile* q = pile_creer();
printf("%d\n", q->n);            /* (b) */
printf("%zu\n", sizeof(pile));   /* (c) */

Les trois lignes sont refusées, et le compilateur donne trois fois le même mot : type incomplet.

(a) error: variable has incomplete type 'pile' (aka 'struct pile_s')
(b) error: incomplete definition of type 'struct pile_s'
(c) error: invalid application of 'sizeof' to an incomplete type 'pile'

L'explication est unique. Une déclaration struct pile_s; sans corps introduit un type dont le compilateur connaît le nom mais ni la taille ni les champs. Il sait donc manipuler des pile* — tous les pointeurs ont la même taille —, mais rien de ce qui exige de connaître la structure :

• (a) réserver une variable demande sa taille : impossible. C'est pourquoi un type opaque impose l'allocation dynamique, donc un creer et un detruire.
• (b) atteindre un champ demande son déplacement dans la structure : impossible. C'est le cœur du procédé — l'invariant ne peut être cassé que depuis le module.
• (c) sizeof demande la taille : impossible, pour la même raison que (a).

Ce que l'opacité permet en échange : remplacer un tableau dynamique par une chaîne de maillons ne change pas une ligne — ni même un octet — du code utilisateur, qui n'a pas besoin d'être relu. Sans opacité, tout code ayant écrit q->n serait à reprendre, et rien ne dirait lesquels.

Le prix, chiffré. Une indirection à chaque accès, un appel de fonction là où il y aurait eu une lecture de champ, et une paire allocation/libération par objet. Le dernier exercice de cette série le mesure.