Bonjour,

Je m'entraîne à la POO en me faisant une librairie de calcul sur des Points dont le type de base est laissé vaquant (template T).
J'ai donc fait une classe de base Point, entièrement abstraite (pas de variable membre, que des méthodes publiques abstraites). Puis j'ai dérivé cette classe en une Classe Vector, contenant aucune variable mais avec des méthodes publiques non abstraites. Enfin, j'ai dérivé de Vector des classes implémentables, avec ce qu'il faut de variables, implémentant toutes les méthodes abstraites et surchargeant certaines méthodes de Vector. Par exemple, une classe Point3D, avec x,y et z comme variables de type T.

Compilation sous Code::Blocks 8.02 sous Windows, environnement natif (donc mingw 3.4.4 il me semble). Pas de warning, tout est ok en debug et en release.

A l'exécution d'un programme test créant un Point3D<char> et faisant quelques manipulations simples (pour tester mes surcharges des opérateurs courants), je fais afficher sizeof(Point3D<char>).
A ma grande surprise, il affiche : 8. En mémoire, je vois un joli en-tête de 4o avant les 3o réservés à mes données.


Alors j'ai simplifié l'architecture globale pour tester ce problème de mémoire. Je garde une seule classe abstraite dont hérite une classe quelconque. Classes template, et 3 variables dans la classe fille de type T.
Voici le code :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <iostream>
 
template<class T>
class prestruct {
public:
  virtual T& f(int) =0;
};
 
template<class T>
class mystruct : public prestruct<T> {
public:
  T x,y,z;
public:
  T& f(int i)
  { return x; }
};
 
int main(int carg, char** varg) {
  cout << sizeof(mystruct<char>); << endl;
  return 0;
}
Quand je lance le code compilé, il m'affiche 8. Même chose, même en-tête.
Maintenant, quand j'enlève "l'abstraction" de la méthode f de la classe mère, i.e. je code un truc au pif, il m'affiche 3. Plus d'en-tête, juste mes données non alignées sur 32 bits (ce que j'aimerais avoir au final).

Quelqu'un pourrait-il me dire ce qui se passe ? Est-ce que ma version de gcc est bien trop vielle ? Est-ce un problème de compilo ?
A noter que les résultats sont les mêmes en release et en débug, qu'en release j'ai enlevé toutes les infos de débogage. J'ai aussi essayé l'option de gcc -fno-rtti, sans succès.

Merci d'éclairer ma lanterne