Continuons cette série sur les codes fantastiques avec une utilisation astucieuse des bits de rembourrage vue dans LLVM.
En C, et a fortiori en C++, il existe deux situations où une structure peut avoir des trous : entre les champs pour aligner convenablement ces derniers, ou en fin de structure :
Sur une machine 64 bits, le premier champ de PommeDeTerre (qu’est-ce qu’on rigole) occupant typiquement 1 octet, et un entier nécessitant d’être aligné sur 4 octets, 3 octets de padding (rembourrage en français o_O) vont être insérés entre ces deux champs. Et comme PommeDeTerre doit elle-même être alignée sur 4 octets, on aura à nouveau 3 octets ajoutés en fin de structure, ce qui nous donne une taille de PommeDeTerre de 12 octets. Même en réordonnant les champs, par exemple dans l’ordre field1, field0, field2, on obtient une PommeDeTerre de 8 octets avec 2 octets de padding.
Bien qu’on puisse le faire avec, par exemple, un memcpy, on ne peut pas en faire grand-chose en restant dans le standard. L’idée utilisée dans la base de code de LLVM est tout simplement de nommer ces champs, afin de les exposer aux classes filles. Cela donnerait dans notre cas la déclaration suivante :
La PommeDeTerre a maintenant un nouveau champ qu’elle n’utilise pas, extra_field, et plus de padding ! De manière assez inhabituelle, c’est une classe fille, ici Ratte, qui l’utilise pour identifier la variété de rattes qu’elle incarne. Ainsi, la Ratte ne prend pas plus de place en mémoire que sa classe mère (elle ne se dilate pas) ! On peut voir une utilisation de cette technique en suivant https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/Metadata.h#L74.
Ce ne sont pas moins de trois champs, SubclassData1, SubclassData16, SubclassData32, qui sont mis à disposition des classes filles. On notera par ailleurs l’usage astucieux d’un bitfield pour contrôler au plus prêt la taille du padding.
Cette optimisation pose néanmoins un problème de maintenabilité : le nommage des champs est forcément générique (la classe mère ne connaît pas par avance les classes filles qui vont dériver d’elle), ce qui ne permet pas de les rattacher à un usage particulier. De plus, dans notre exemple il ne serait pas valable pour une classe dérivant de Ratte d’utiliser le champ extra_field pour son propre usage, car Ratte l’utilise déjà, mais cela implique que le développeur inspecte manuellement toute la chaîne d’héritage pour le vérifier.
Mais je vois déjà les lecteurs les plus enthousiastes mentionner qu’avec un peu de métaprogrammation...
