Alignement et héritage

Bonjour,

J'aimerais savoir si ces bouts de code sont sûrs :

Code:

---

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

// Partie non accessible uneClasse obj;   (...)   // Partie accessible obj.~uneClasse(); new(&obj) uneSousClasse(); (...) reinterpret_cast<uneSousClasse *>( &obj )->~uneSousClasse(); new(&obj) uneClasse();   //==================================//   // Partie non accessible uneClasse *obj = new uneClasse();   (...)   // Partie accessible obj->~uneClasse() new(obj) uneSousClasse(); (...) reinterpret_cast<uneSousClasse *>( obj )->~uneSousClasse(); new(obj) uneClasse();   (...)   // Partie non accessible delete obj;

---

sachant que :

• uneSousClasse et une sous-classe de uneClasse ;
• uneSousClasse ne définit aucun attribut membre ni aucun membre statique (attribut ou fonction) ;
• le destructeur de la classe uneClasse n'est pas (forcément) virtuel ;
• je n'ai pas accès à la classe uneClasse ;
• je n'ai pas forcément accès à la classe uneSousClasse ;
• je n'ai pas accès à la création de l'objet (ni à sa destruction).

Je sais que ce n'est pas propre, mais je n'ai pas vraiment le choix... :(

Merci d'avance. :)

Edit : J'ai ajouté la gestion de la destruction des objets.

Salut,

J'ai l'impression que tu es mur pour... foncer dans le mur :aie:

Tu ne nous donnes pas assez d'information concernant tes classes, mais, étant donné que tu utilise ne placement new, tu cours le gros risque de voir certains membre de ta classe UneSousClasse se retrouver à une adresse mémoire qui n'est pas réservée, étant donné que sizeof(UneSousClasse) sera, très vraisemblablement plus grand que sizeof(UneClasse).

Désolé ;)

Arf...
Moi qui pensait que comme la sous-classe ne définit que des fonctions membres non statiques, les instances auraient la même taille... :cry:

Concernant les informations sur les classes, d'après ce que j'ai lu (et compris...) sur l'alignement et le placement new, je pensais avoir mis tout ce qui était nécessaire...
Qu'est-ce qui manque ?

Au passage, la question m'est venue avec des classes de la STL.
Bah quoi ? je voulais juste adapter une classe prédéfinie à mes besoins, sans pour autant réinventer la roue...

Code:

---

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

namespace std {   class uneClasse {   public: ~uneClasse() {...}   (...)   };   class uneSousClasse : public uneClasse { (...) };     class uneAutreClasse {   protected: uneClasse _attribut;   (...)   };   }

---

J'ai besoin des fonctionnalités de la classe uneAutreClasse, sauf que _attribut doit être une instance de uneSousClasse.

Bon, je pourrais réécrire la classe uneAutreClasse, mais bon, hum... :?
Ceci dit, si vous avez une meilleure idée, je suis preneur.

Citation:

---

le destructeur de la classe uneClasse n'est pas (forcément) virtuel ;

---

Ceci couplé avec l'exemple 2, conduit à un code qui peut potentiellement faire n'importe quoi.

Il est difficile de donner un avis dans l'abstrait ainsi, mais voici quelques remarques en vrac :

- Je pense que le code 1 a des chances de "marcher" sur pas mal d'implémentations, tant que tu ne copies pas obj, mais il y a des chances que ce ne soit pas formellement autorisé (je n'ai pas eu le courage de regarder dans le standard).
- Comme dit Flob, le 2 pose problème.
- Meilleure idée 1 (?) : A quoi sert vraiment uneSousClasse, sans données, sans fonctions, sans rien ? Ne serait-il pas possible de la remplacer par des fonctions libres prenant un uneClasse& en paramètre ?
- Meilleure idée 2 (?) : Tu es propriétaire de uneAutreClasse ? Peut-être pourrais-tu la templater ? Ou lui passer en argument une fonction de factory (et utiliser un pointeur) ?

Citation:

---

Envoyé par JolyLoic

- Je pense que le code 1 a des chances de "marcher" sur pas mal d'implémentations, tant que tu ne copies pas obj, mais il y a des chances que ce ne soit pas formellement autorisé (je n'ai pas eu le courage de regarder dans le standard).
- Comme dit Flob, le 2 pose problème.

---

Le cas 1 posera au moins autant de problèmes que le cas 2 au niveau de l'appel du destructeur :aie:, car avec ou sans destructeur virtuel, le compilateur utilisera dans tous les cas uneClasse::~uneClasse lorsque l'on sortira de la portée de uneClasse obj;.

Citation:

---

Envoyé par gb_68

car avec ou sans destructeur virtuel, le compilateur utilisera dans tous les cas uneClasse::~uneClasse lorsque l'on sortira de la portée de uneClasse obj;.

---

Désolé, j'avais oublié de détruire explicitement l'instance de la sous-classe.
J'y avais pensé quand j'avais testé, mais là... :aie:

Oui, j'avais testé, et ça avait marché !
Et sans fuite mémoire, en plus !
Mais je n'ai jamais pu savoir si c'était un coup de bol ou pas...

Citation:

---

Envoyé par JolyLoic

Je pense que le code 1 a des chances de "marcher" sur pas mal d'implémentations, tant que tu ne copies pas obj, mais il y a des chances que ce ne soit pas formellement autorisé

---

Ah, je n'y ai pas pensé à la copie. :oops:
Ce doit être parce la classe uneAutreClasse n'est pas copiable.

Citation:

---

Envoyé par JolyLoic

A quoi sert vraiment uneSousClasse, sans données, sans fonctions, sans rien ?

---

Euh, je n'ai jamais dit qu'il n'y avait pas de fonction dans uneSousClasse.
En fait, il n'y a que des fonctions membres non statiques.
Elle sert juste à étendre les possibilités, avec les mêmes données.

Citation:

---

Envoyé par JolyLoic

Tu es propriétaire de uneAutreClasse ?

---

A priori, non.

Citation:

---

Envoyé par JolyLoic

Il est difficile de donner un avis dans l'abstrait ainsi, (...)

---

Désolé, j'ai trop pris l'habitude d'abstraire au maxmium... :oops: :oops: :oops:
Alors voilà un cas concret :

• uneClasse = std::filebuf
• uneSousClasse = __gnu_cxx::stdio_filebuf<char>
• uneAutreClasse = std::fstream

Pour ceux qui ne se sont pas amusés à décortiquer le code de la STL, les flux sur les fichiers (fstream) utilisent un buffer interne (de type filebuf) alloué statiquement.
Ce buffer ne permet d'ouvrir un fichier qu'à partir de son chemin (donc un char*).
Mais si l'on ne dispose que d'un FILE* ou d'un descripteur de fichier ?
La réponse est donnée par la classe stdio_filebuf (si disponible), sous-classe de filebuf, qui est une extension GNU.

Alors évidemment, je pourrais utiliser directement les fonctions C pour manipuler mon fichier.
Mais et l'approche objet, alors ?
Et puis les classes de flux C++ ont des fonctionnalités bien pratiques...

Donc il me suffirait de créer mon buffer (stdio_filebuf) à partir de FILE* ou du descripteur de fichier, puis d'associer ce buffer à un flux (std::istream, std::ostream ou std::iostream) et le tour est joué.
Par contre, une fois que j'ai fini, il faut que je pense à bien fermer le fichier et détruire le buffer si nécessaire.

Pfff...
D'après ce que j'ai vu, les classes fstream automatisent ces tâches, et gèrent correctement les erreurs.
Du coup, ça pourrait donner quelque chose du genre (en simplifiant ce qui n'est pas essentiel) :

Code:

---

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 53 54 55 56 57 58 59 60 61

class mystream : public std::fstream {   private: typedef std::fstream _base; typedef std::filebuf filebuf_old;   public: typedef __gnu_cxx::stdio_filebuf<char> filebuf_type;   mystream() : _base() { _M_filebuf.~filebuf_old(); new(&_M_filebuf) filebuf_type; }   mystream(const char* filename) : _base() { _M_filebuf.~filebuf_old(); new(&_M_filebuf) filebuf_type(); _base::open(filename); }   mystream(FILE* fp) : _base() { _M_filebuf.~filebuf_old(); new(&_M_filebuf) filebuf_type(fp); if (!_M_filebuf.is_open()) this->clear(std::failbit); }   mystream(int fd) : _base() { _M_filebuf.~filebuf_old(); new(&_M_filebuf) filebuf_type(fd); if (!_M_filebuf.is_open()) this->clear(std::failbit); }     ~mystream() { reinterpret_cast<filebuf_type&>( _M_filebuf ).~filebuf_type(); new(&_M_filebuf) filebuf_old(); }     using _base::open;   void open(FILE* fp) { reinterpret_cast<filebuf_type&>( _M_filebuf ).~filebuf_type(); new(&_M_filebuf) filebuf_type(fp); if (!_M_filebuf.is_open()) this->clear(std::failbit); }   void open(int fd) { reinterpret_cast<filebuf_type&>( _M_filebuf ).~filebuf_type(); new(&_M_filebuf) filebuf_type(fd); if (!_M_filebuf.is_open()) this->clear(std::failbit); }   (...)   };

---

PS: La classe stdio_filebuf n'a pas de fonction membre "open" comme filebuf.

Bon, je ne me souviens plus exactement comment est gérée l'erreur d'ouverture, j'ai écrit ça de mémoire.
Et normalement il faudrait vérifier que le flux n'est pas déjà ouvert avant d'essayer de l'ouvrir, mais comme j'ai que je simplifiais...

Au fait, si j'appelais le constructeur comme une fonction membre normale (au lieu du placement new), à l'instar du destructeur, qu'est-ce qu'il se passerait (toujours avec les mêmes contraintes) ?

Code:

---

1 2 3 4 5 6 7

uneClasse obj; (...) obj.~uneClasse(); new(&obj) uneSousClasse(); (...) reinterpret_cast<uneSousClasse&>( obj ).~uneSousClasse(); obj.uneClasse();

---

Après tout, si j'ai bien compris comment ça marche, la création et la destruction implicites (allocation statique) ou explicites (allocation dynamique) d'un objet se déroulent en deux étapes :

• Pour la construction :
  
  1. Allocation/Réservation de la mémoire ;
  2. Appel du constructeur.
• Pour la destruction :
  
  1. Appel du destructeur ;
  2. Libération de la mémoire.

Tu ne peus pas appeler un constructeur explictement n3126 12.1 2 .

Citation:

---

Envoyé par Flob90

Tu ne peus pas appeler un constructeur explictement n3126 12.1 2 .

---

tu fais un new de placement je pense que ca passe ?

Citation:

---

Because constructors do not have names, they are never found during name lookup;

---

Ca implique que tout appel direct au constructeur (ie mon_objet.MaClass() ), est impossible (la fonction ne doit pas être trouvé d'après la norme).

Dit autrement : tout appel au constructeur est implicite. Et lors d'un placement (classique) new, c'est bien la syntaxe particulière de new (de manière général et pas que pour le placement d'ailleurs) qui permet un appel de manière implicite au constructeur.

Tous ca pour dire que la fin du code proposé par Steph_ng8 ne peut pas marcher (obj.uneClasse();)

Hum... En y repensant, je crois que j'avais essayé il y a longtemps...
Mais bon c'était il y a longtemps... :roll:

Par contre, j'ai l'impression que je le suis mélangé les pinceaux... :aie:
En fait, le destructeur de uneClasse est bel et bien virtuel... :oops:
J'ai dû confondre avec un autre problème... :oops: :oops: :oops:

Du coup, ça change quelque chose ?
(en tenant compte des modifications que j'ai apportées aux codes du premier post)