avant ma question, voici les données :
class cA
{
protected:
double d;
public:
cA(const double& d =0.0) { this->d = d; }
~cA(void) {}
};
class cB
{
protected:
double d;
public:
cB(const double& d =0.0) { this->d = d; }
virtual ~cB(void) {}
};
cout << "sizeof(cA) = " << sizeof(cA) << endl; // => 8
cout << "sizeof(cB) = " << sizeof(cB) << endl; // => 16
est-ce normal ?
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
avant ma question, voici les données :
class cA
{
protected:
double d;
public:
cA(const double& d =0.0) { this->d = d; }
~cA(void) {}
};
class cB
{
protected:
double d;
public:
cB(const double& d =0.0) { this->d = d; }
virtual ~cB(void) {}
};
cout << "sizeof(cA) = " << sizeof(cA) << endl; // => 8
cout << "sizeof(cB) = " << sizeof(cB) << endl; // => 16
est-ce normal ?
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
avant ma question, voici les données :
class cA
{
protected:
double d;
public:
cA(const double& d =0.0) { this->d = d; }
~cA(void) {}
};
class cB
{
protected:
double d;
public:
cB(const double& d =0.0) { this->d = d; }
virtual ~cB(void) {}
};
cout << "sizeof(cA) = " << sizeof(cA) << endl; // => 8
cout << "sizeof(cB) = " << sizeof(cB) << endl; // => 16
est-ce normal ?
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Bonjour,
avant ma question, voici les données :
class cA
{
protected:
double d;
public:
cA(const double& d =0.0) { this->d = d; }
~cA(void) {}
};
class cB
{
protected:
double d;
public:
cB(const double& d =0.0) { this->d = d; }
virtual ~cB(void) {}
};
cout << "sizeof(cA) = " << sizeof(cA) << endl; // => 8
cout << "sizeof(cB) = " << sizeof(cB) << endl; // => 16
est-ce normal ?
peut-on garder une taille de 8 en utilisant des fonctions
virtuelles ?
Bonjour,
avant ma question, voici les données :
class cA
{
protected:
double d;
public:
cA(const double& d =0.0) { this->d = d; }
~cA(void) {}
};
class cB
{
protected:
double d;
public:
cB(const double& d =0.0) { this->d = d; }
virtual ~cB(void) {}
};
cout << "sizeof(cA) = " << sizeof(cA) << endl; // => 8
cout << "sizeof(cB) = " << sizeof(cB) << endl; // => 16
est-ce normal ?
peut-on garder une taille de 8 en utilisant des fonctions
virtuelles ?
Bonjour,
avant ma question, voici les données :
class cA
{
protected:
double d;
public:
cA(const double& d =0.0) { this->d = d; }
~cA(void) {}
};
class cB
{
protected:
double d;
public:
cB(const double& d =0.0) { this->d = d; }
virtual ~cB(void) {}
};
cout << "sizeof(cA) = " << sizeof(cA) << endl; // => 8
cout << "sizeof(cB) = " << sizeof(cB) << endl; // => 16
est-ce normal ?
peut-on garder une taille de 8 en utilisant des fonctions
virtuelles ?
Bonjour,
avant ma question, voici les données :
class cA
{
protected:
double d;
public:
cA(const double& d =0.0) { this->d = d; }
~cA(void) {}
};
class cB
{
protected:
double d;
public:
cB(const double& d =0.0) { this->d = d; }
virtual ~cB(void) {}
};
cout << "sizeof(cA) = " << sizeof(cA) << endl; // => 8
cout << "sizeof(cB) = " << sizeof(cB) << endl; // => 16
est-ce normal ?
Oui : Sur tous les compilateurs courants, le fait d'avoir une fonction
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Non. Le plus petit que tu puisse *peut être* obtenir c'est sizeof(double) +
Bonjour,
avant ma question, voici les données :
class cA
{
protected:
double d;
public:
cA(const double& d =0.0) { this->d = d; }
~cA(void) {}
};
class cB
{
protected:
double d;
public:
cB(const double& d =0.0) { this->d = d; }
virtual ~cB(void) {}
};
cout << "sizeof(cA) = " << sizeof(cA) << endl; // => 8
cout << "sizeof(cB) = " << sizeof(cB) << endl; // => 16
est-ce normal ?
Oui : Sur tous les compilateurs courants, le fait d'avoir une fonction
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Non. Le plus petit que tu puisse *peut être* obtenir c'est sizeof(double) +
Bonjour,
avant ma question, voici les données :
class cA
{
protected:
double d;
public:
cA(const double& d =0.0) { this->d = d; }
~cA(void) {}
};
class cB
{
protected:
double d;
public:
cB(const double& d =0.0) { this->d = d; }
virtual ~cB(void) {}
};
cout << "sizeof(cA) = " << sizeof(cA) << endl; // => 8
cout << "sizeof(cB) = " << sizeof(cB) << endl; // => 16
est-ce normal ?
Oui : Sur tous les compilateurs courants, le fait d'avoir une fonction
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Non. Le plus petit que tu puisse *peut être* obtenir c'est sizeof(double) +
est-ce normal ?
Oui.peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Ben, ça va être dur. Dans un polymorphisme dynamique,
il faut pouvoir, à l'exécution, savoir retrouver le type
réel de l'objet. Et cela demande un peu plus d'info
que sur un typage statique.
Marc Boyer
est-ce normal ?
Oui.
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Ben, ça va être dur. Dans un polymorphisme dynamique,
il faut pouvoir, à l'exécution, savoir retrouver le type
réel de l'objet. Et cela demande un peu plus d'info
que sur un typage statique.
Marc Boyer
est-ce normal ?
Oui.peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Ben, ça va être dur. Dans un polymorphisme dynamique,
il faut pouvoir, à l'exécution, savoir retrouver le type
réel de l'objet. Et cela demande un peu plus d'info
que sur un typage statique.
Marc Boyer
Oui : Sur tous les compilateurs courants, le fait d'avoir une fonction
virtuelle dans une classe signifie que un objet de ce type embarque une
donnée membre cachée "v-ptr" (pour "virtual pointer") qui pointe sur une
description générée par le compilateur du type réel de l'objet (le plus
souvent, cette description est appelée la "v-table" parce qu'elle contient
entre autres choses une table de pointeurs sur les méthodes virtuelles de la
classe). Par contre, ce surcout est fixe et n'augmente pas avec le nombre de
méthodes virtuelles.
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Non. Le plus petit que tu puisse *peut être* obtenir c'est sizeof(double) +
taille d 'un pointeur, soit 12 sur les machines 32 bits courantes, en jouant
sur les options d'alignement et de padding du compilateur (ce qui dégradera
probablement les performances, si c'est seulement possible).
C'est si important que çà?
Oui : Sur tous les compilateurs courants, le fait d'avoir une fonction
virtuelle dans une classe signifie que un objet de ce type embarque une
donnée membre cachée "v-ptr" (pour "virtual pointer") qui pointe sur une
description générée par le compilateur du type réel de l'objet (le plus
souvent, cette description est appelée la "v-table" parce qu'elle contient
entre autres choses une table de pointeurs sur les méthodes virtuelles de la
classe). Par contre, ce surcout est fixe et n'augmente pas avec le nombre de
méthodes virtuelles.
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Non. Le plus petit que tu puisse *peut être* obtenir c'est sizeof(double) +
taille d 'un pointeur, soit 12 sur les machines 32 bits courantes, en jouant
sur les options d'alignement et de padding du compilateur (ce qui dégradera
probablement les performances, si c'est seulement possible).
C'est si important que çà?
Oui : Sur tous les compilateurs courants, le fait d'avoir une fonction
virtuelle dans une classe signifie que un objet de ce type embarque une
donnée membre cachée "v-ptr" (pour "virtual pointer") qui pointe sur une
description générée par le compilateur du type réel de l'objet (le plus
souvent, cette description est appelée la "v-table" parce qu'elle contient
entre autres choses une table de pointeurs sur les méthodes virtuelles de la
classe). Par contre, ce surcout est fixe et n'augmente pas avec le nombre de
méthodes virtuelles.
peut-on garder une taille de 8 en utilisant des fonctions virtuelles ?
Non. Le plus petit que tu puisse *peut être* obtenir c'est sizeof(double) +
taille d 'un pointeur, soit 12 sur les machines 32 bits courantes, en jouant
sur les options d'alignement et de padding du compilateur (ce qui dégradera
probablement les performances, si c'est seulement possible).
C'est si important que çà?
Dans quel but as-tu besoin d'avoir cette information ?
En fonction du problème à résoudre, il a surement une méthode plus
adaptée à ton cas.
Dans quel but as-tu besoin d'avoir cette information ?
En fonction du problème à résoudre, il a surement une méthode plus
adaptée à ton cas.
Dans quel but as-tu besoin d'avoir cette information ?
En fonction du problème à résoudre, il a surement une méthode plus
adaptée à ton cas.
Ben, ça va être dur. Dans un polymorphisme dynamique,
il faut pouvoir, à l'exécution, savoir retrouver le type
réel de l'objet. Et cela demande un peu plus d'info
que sur un typage statique.
Il me semblait bien mais le rêve reste permis ;-p
En fait ce qui me choque plus c'est que la taille ne soit pas 12, je pensais
qu'un pointeur suffisait pour la table virtuelle.
Et je croyais naîvement aussi que pour la classe mère la table virtuelle était
inutile (j'en reste convaincu mais apparemment l'économie n'est pas faite) et
qu'elle n'était utilisée que pour des instances de classes filles.
Ben, ça va être dur. Dans un polymorphisme dynamique,
il faut pouvoir, à l'exécution, savoir retrouver le type
réel de l'objet. Et cela demande un peu plus d'info
que sur un typage statique.
Il me semblait bien mais le rêve reste permis ;-p
En fait ce qui me choque plus c'est que la taille ne soit pas 12, je pensais
qu'un pointeur suffisait pour la table virtuelle.
Et je croyais naîvement aussi que pour la classe mère la table virtuelle était
inutile (j'en reste convaincu mais apparemment l'économie n'est pas faite) et
qu'elle n'était utilisée que pour des instances de classes filles.
Ben, ça va être dur. Dans un polymorphisme dynamique,
il faut pouvoir, à l'exécution, savoir retrouver le type
réel de l'objet. Et cela demande un peu plus d'info
que sur un typage statique.
Il me semblait bien mais le rêve reste permis ;-p
En fait ce qui me choque plus c'est que la taille ne soit pas 12, je pensais
qu'un pointeur suffisait pour la table virtuelle.
Et je croyais naîvement aussi que pour la classe mère la table virtuelle était
inutile (j'en reste convaincu mais apparemment l'économie n'est pas faite) et
qu'elle n'était utilisée que pour des instances de classes filles.
Dans quel but as-tu besoin d'avoir cette information ?
En fonction du problème à résoudre, il a surement une méthode plus
adaptée à ton cas.
Dans mon appli je travaille avec des BlobTrees qui sont des arbres CSG enrichis,
c'est-à-dire qu'un objet (3D) est défini par des mélanges, unions, intersections
et différences de primitiives géométriques.
Ces primitives sont composés d'un squelette géométrique et d'une peau implicite
(pour les mélanges).
Chaque squelette est composé de points, vecteurs et quelques grandeurs.
Comme les modèles sont animés, en fait il s'agit de trajectoires, vecteurs
dépendants du temps et grandeurs variables.
Et enfin si je me restreint aux trajectoires j'ai besoin que certaines soient
définies relativement à d'autres (gestion et édition simplifiée) donc j'utilise
beaucoup des compositions de trajectoires, vecteurs et gandeurs.
Si on ajoute à ça le fait que ces modèles sont à niveaux de détails, finalement
la structure est assez importante mais surtout elle ne contient que des objets
qui sont des instances de classes virtuelles (de BlobTrees, de primitives, de
squelettes, des trajectoires, ...).
Et comme ce qui m'intéresse vraiment est de gérer plusieurs objets et de faire
des transformations entre eux...
Bref ça coûte finalement assez cher ces 8+8+...+8 octets en plus pour chaque
virtual.
Je n'y avais jamais trop réfléchi avant mais comme je suis en train de tout
recoder pour avoir une architecture ds mes libs plus propre, je voudrais faire
les choses bien.
Je ne vois pas trop si c'est améliorable finalement.
Dans quel but as-tu besoin d'avoir cette information ?
En fonction du problème à résoudre, il a surement une méthode plus
adaptée à ton cas.
Dans mon appli je travaille avec des BlobTrees qui sont des arbres CSG enrichis,
c'est-à-dire qu'un objet (3D) est défini par des mélanges, unions, intersections
et différences de primitiives géométriques.
Ces primitives sont composés d'un squelette géométrique et d'une peau implicite
(pour les mélanges).
Chaque squelette est composé de points, vecteurs et quelques grandeurs.
Comme les modèles sont animés, en fait il s'agit de trajectoires, vecteurs
dépendants du temps et grandeurs variables.
Et enfin si je me restreint aux trajectoires j'ai besoin que certaines soient
définies relativement à d'autres (gestion et édition simplifiée) donc j'utilise
beaucoup des compositions de trajectoires, vecteurs et gandeurs.
Si on ajoute à ça le fait que ces modèles sont à niveaux de détails, finalement
la structure est assez importante mais surtout elle ne contient que des objets
qui sont des instances de classes virtuelles (de BlobTrees, de primitives, de
squelettes, des trajectoires, ...).
Et comme ce qui m'intéresse vraiment est de gérer plusieurs objets et de faire
des transformations entre eux...
Bref ça coûte finalement assez cher ces 8+8+...+8 octets en plus pour chaque
virtual.
Je n'y avais jamais trop réfléchi avant mais comme je suis en train de tout
recoder pour avoir une architecture ds mes libs plus propre, je voudrais faire
les choses bien.
Je ne vois pas trop si c'est améliorable finalement.
Dans quel but as-tu besoin d'avoir cette information ?
En fonction du problème à résoudre, il a surement une méthode plus
adaptée à ton cas.
Dans mon appli je travaille avec des BlobTrees qui sont des arbres CSG enrichis,
c'est-à-dire qu'un objet (3D) est défini par des mélanges, unions, intersections
et différences de primitiives géométriques.
Ces primitives sont composés d'un squelette géométrique et d'une peau implicite
(pour les mélanges).
Chaque squelette est composé de points, vecteurs et quelques grandeurs.
Comme les modèles sont animés, en fait il s'agit de trajectoires, vecteurs
dépendants du temps et grandeurs variables.
Et enfin si je me restreint aux trajectoires j'ai besoin que certaines soient
définies relativement à d'autres (gestion et édition simplifiée) donc j'utilise
beaucoup des compositions de trajectoires, vecteurs et gandeurs.
Si on ajoute à ça le fait que ces modèles sont à niveaux de détails, finalement
la structure est assez importante mais surtout elle ne contient que des objets
qui sont des instances de classes virtuelles (de BlobTrees, de primitives, de
squelettes, des trajectoires, ...).
Et comme ce qui m'intéresse vraiment est de gérer plusieurs objets et de faire
des transformations entre eux...
Bref ça coûte finalement assez cher ces 8+8+...+8 octets en plus pour chaque
virtual.
Je n'y avais jamais trop réfléchi avant mais comme je suis en train de tout
recoder pour avoir une architecture ds mes libs plus propre, je voudrais faire
les choses bien.
Je ne vois pas trop si c'est améliorable finalement.
Et je croyais naîvement aussi que pour la classe mère la table virtuelle était
inutile (j'en reste convaincu mais apparemment l'économie n'est pas faite) et
qu'elle n'était utilisée que pour des instances de classes filles.
Oui, mais quand il tombe sur un pointeur A* p, il va devoir lire
*p pour savoir dynamiquement si c'est la mère ou la fille. Donc,
il faut que même dans le cas de la mère, il existe une info qui
dise "je suis la mère".
Marc Boyer
Et je croyais naîvement aussi que pour la classe mère la table virtuelle était
inutile (j'en reste convaincu mais apparemment l'économie n'est pas faite) et
qu'elle n'était utilisée que pour des instances de classes filles.
Oui, mais quand il tombe sur un pointeur A* p, il va devoir lire
*p pour savoir dynamiquement si c'est la mère ou la fille. Donc,
il faut que même dans le cas de la mère, il existe une info qui
dise "je suis la mère".
Marc Boyer
Et je croyais naîvement aussi que pour la classe mère la table virtuelle était
inutile (j'en reste convaincu mais apparemment l'économie n'est pas faite) et
qu'elle n'était utilisée que pour des instances de classes filles.
Oui, mais quand il tombe sur un pointeur A* p, il va devoir lire
*p pour savoir dynamiquement si c'est la mère ou la fille. Donc,
il faut que même dans le cas de la mère, il existe une info qui
dise "je suis la mère".
Marc Boyer