std::tuple sizeof, est-ce une optimisation manquée ?

Question

J'ai vérifié tous les principaux compilateurs, et sizeof(std::tuple<int, char, int, char>) est de 16 pour chacun d'entre eux. On peut supposer qu'ils se contentent de placer les éléments dans l'ordre dans le n-uplet, de sorte qu'une partie de l'espace est perdue en raison de l'alignement.

Si les éléments du tuple sont stockés en interne comme : int, int, char, char alors sa taille pourrait être de 12.

Est-il possible pour une implémentation de faire cela, ou est-ce interdit par une règle de la norme ?

Answer 1

std::tuple sizeof, est-ce une optimisation manquée ?

Oui.

Est-il possible pour une mise en œuvre de le faire ?

Oui.

[Est-ce interdit par une règle de la norme ?

Non !

Lire à travers [tuple] il n'y a aucune contrainte imposée à l'implémentation pour stocker les membres dans l'ordre des arguments du modèle.

En fait, tous les passages que j'ai pu trouver semblent s'efforcer d'éviter toute référence à l'ordre de déclaration des membres : get<N>() est utilisé dans la description de la sémantique opérationnelle. D'autres formulations sont énoncées en termes d'"éléments" plutôt que de "membres", ce qui semble être une abstraction délibérée.

En effet, certaines implémentations stockent apparemment les membres dans l'ordre inverse au moins, probablement simplement en raison de la façon dont ils utilisent l'héritage de manière récursive pour décompresser les arguments du modèle (et parce que, comme indiqué ci-dessus, ils y sont autorisés).

En ce qui concerne spécifiquement votre optimisation hypothétique, je ne connais aucune implémentation qui ne stocke pas les éléments dans [une fonction triviale de] l'ordre donné par l'utilisateur ; je suppose qu'il serait "difficile" de trouver un tel ordre et de fournir la machinerie pour le stockage des éléments. std::get du moins par rapport au gain que vous obtiendriez en agissant de la sorte. Si vous êtes vraiment préoccupé par le remplissage, vous pouvez bien sûr choisir soigneusement l'ordre de vos éléments pour l'éviter (sur une plate-forme donnée), comme vous le feriez avec une classe (sans plonger dans le monde des attributs "emballés"). (Un tuple "emballé" pourrait être une proposition intéressante )

Answer 2

Oui, c'est possible et cela a été fait (en grande partie) par R. Martinho Fernandes . Il tenait un blog intitulé Zone de danger de flammes qui est maintenant hors service pour une raison quelconque, mais son les sources sont toujours disponibles sur github .

Voici les quatre parties de la L'importance de la taille sur ce sujet précis : 1 , 2 , 3 , 4 .

Vous souhaiterez peut-être les voir bruts car github ne comprend pas le marquage de mise en évidence C++ utilisé et rend les extraits de code sous forme d'oneliners illisibles.

Il calcule essentiellement une permutation pour les indices de tuple via le métaprogramme modèle C++11, qui trie les éléments par alignement dans un ordre non ascendant, stocke les éléments en fonction de cette permutation, puis l'applique à l'index lors de chaque accès.

Answer 3

Ils pourraient le faire. Une raison possible pour laquelle ils ne le font pas : certaines architectures, y compris x86, ont un mode d'indexation qui peut adresser une adresse base + taille × index en une seule instruction, mais seulement lorsque taille est une puissance de 2. Il peut aussi être légèrement plus rapide d'effectuer un chargement ou un stockage aligné sur une frontière de 16 octets. Cela pourrait rendre le code qui adresse des tableaux de std::tuple légèrement plus rapides et plus compacts s'ils ajoutent quatre octets de remplissage.