Vs Compilateur x64 - x86

Le problème exposé dans ce sujet a été résolu.

Salut, Voilà ça :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
#include "stdafx.h"
#include <iostream>


class Entity {
public:

    float x, y;

    void Move(float xa, float ya) {
        x += xa;
        y += ya;
    }




};
class Player : public Entity{
public:

    const char* name;

    Player() {
        name = "Player";
    }

    void PrintName() {
        std::cout << name << std::endl;
    }


};



int main()
{
    std::cout << sizeof(Player) << std::endl;


        //Non important 
    Player player;
    player.PrintName();
    player.Move(5.0f, 2.0f);




    return 0;

}

Quand je compile (std::cout « sizeof(Player) « std::endl;) en x86, j’ai 12 comme résultat alors qu’en compilant en x64, j’ai 16 comme résultat, pourquoi une différence entre les 2 résultats ? :D

+0 -0

la taille de ton pointeur "name". Un pointeur fait la taille du bus(?) du CPU, donc 32 bits si le code est compilé en 32 bits, et 64 pour du 64 bits. Donc 4 et 8 octets respectivements, ce qui donne le "+4".

minirop

Salut,

Juste pour essayer de préciser un peu afin que l’OP se renseigne de son côté si il veut. Il me semble que la taille d’un pointeur en C et C++ dépend de plusieurs facteurs. Ca dépend notamment de l’architecture du processeur (la taille de ses registres internes), de la taille de ses bus d’adressage et de données, du système d’exploitation et du compilateur utilisé.

Ainsi sur les processeurs "usuels", en 32 bits par exemple, 32 bits correspond à la fois à la taille d’un registre interne au processeur (où il stocke le pointeur) et à la taille de son bus d’adressage (qu’il utilise pour accéder à la valeur mémoire pointée par ton pointeur). Du coup ça ne pose pas de problèmes d’avoir un pointeur occupant 32 bits. Idem pour les architectures 64 bits avec des pointeurs sur 64 bits. Cependant il existe également une multitude d’architectures plus "exotiques" où la taille des registres est différente de celle du bus d’adressage. Dans ces cas-là tu ne peux pas partir du principe que architecture 32 bits == pointeurs sur 32 bits.

+2 -0

la taille de ton pointeur "name". Un pointeur fait la taille du bus(?) du CPU, donc 32 bits si le code est compilé en 32 bits, et 64 pour du 64 bits. Donc 4 et 8 octets respectivements, ce qui donne le "+4".

minirop

Salut,

Juste pour essayer de préciser un peu afin que l’OP se renseigne de son côté si il veut. Il me semble que la taille d’un pointeur en C et C++ dépend de plusieurs facteurs. Ca dépend notamment de l’architecture du processeur (la taille de ses registres internes), de la taille de ses bus d’adressage et de données, du système d’exploitation et du compilateur utilisé.

Ainsi sur les processeurs "usuels", en 32 bits par exemple, 32 bits correspond à la fois à la taille d’un registre interne au processeur (où il stocke le pointeur) et à la taille de son bus d’adressage (qu’il utilise pour accéder à la valeur mémoire pointée par ton pointeur). Du coup ça ne pose pas de problèmes d’avoir un pointeur occupant 32 bits. Idem pour les architectures 64 bits avec des pointeurs sur 64 bits. Cependant il existe également une multitude d’architectures plus "exotiques" où la taille des registres est différente de celle du bus d’adressage. Dans ces cas-là tu ne peux pas partir du principe que architecture 32 bits == pointeurs sur 32 bits.

skywhi

:D

+0 -0

Juste pour compléter les réponses de mes VDD, le compilateur lui-même à une influence. Quand vous choisissez une compilation 32bits, le compilateur fait une tambouille pour que le code binaire généré soit optimum sur le type de machine cible de type 32bits (si la cible c’est "blend", on fait un mixte encore plus infâme pour qu’il soit pas trop lent sur l’ensemble des architecture 32bits). Idem quand on fait du 64bits, le compilateur fait sa tambouille. Il se trouve que c’est plus avantageux (le compilateur considère) de laisser un peu de place vide dans la représentation interne de la classe Player en 32bits (2 floats => 2 * 4octets => 8octets), pour atteindre 12 octets, 4 octets ont été "réservés" soit entre les champs x et y pour que les champs soient alignés sur des adresses multiples de 8, soit en fin ou en début de structure (j’aurais pas d’explication, mais si le compilateur le fait, c’est qu’il a de très bonnes raisons). En 64 bits, le compilateur considère que l’alignement des données n’est peut-être pas si important (prefetching plus malin du CPU, etc…), il colle dont un pointeur 64bits (8octets) directement après les 2 champs floats qui eux sont aussi collés.

Toute cette tambouille varie énormément en fonction des options de compilation et il ne faut donc jamais faire d’assertion sur les tailles des objets. C’est extrêmement fluctuant.

Si la taille des objets ou le "layout" des champs devient une chose importante (interopérabilité avec d’autres langage, etc…), vous devrez commencer à maitriser tout plein d’options pour contrôler un peu le compilateur dans ses délire d’optimisation (#pragma pack, etc…)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte