Éviter l'inclusion des fichiers d'entête de la STL dans son entête

Bonjour,

Aujourd'hui je cherche une méthode pour pouvoir éviter d'inclure les entêtes de la STL dans mes propres entêtes.
Précisément, je cherche à éviter d'écrire ceci

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#ifndef __MONFICHIER_HPP__ #define __MONFICHIER_HPP__ #include <string> class MaClass { private: std::string message; }; #endif

---

Voilà, ce que j'aimerais donc, c'est d'enlever ce '#include <string>' de l'entête, afin d'éviter que lorsque je vais inclure mon fichier, d'avoir accès aux fonctions de string.

Habituellement, j'utilise 'class MaClass', pour faire une déclaration qui sera définie un peu plus tard, mais comme string n'est pas un pointeur, le compilateur n'accepte pas ( ce que je comprends ).
Alors comment puis je faire?

Merci

Salut,

voilà une demande bien surprenante...

Le fait est que tu ne peux envisager d'utiliser la déclaration anticipée d'une classe que si tu ne fait que déclarer une référence ou un pointeur vers un objet de cette classe.

Donc, et bien que je ne voie absolument pas le but de la manoeuvre (pourrais tu m'éclairer sur le sujet :question:), l'idée générale serait de

1. faire une déclaration anticipée de std::string
2. déclarer une pointeur (ou une référence) de type std::string dans ta classe
3. inclure le fichier d'en-tête <string> dans ton *.cpp
4. devoir gérer l'allocation et la libération dynamique de la mémoire "a mano", ce qui, en soit, me semble être un non-sens :P

Cela devrait pouvoir être fait sous une forme proche de
MaClass.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#ifndef MACLASS_H #define MACLASS_H /* déclaration anticipée de string */ namespace std { class string; }; class MaClass { public: MaClass(/* char* str */); ~MaClass(); /*...*/ private: std::string * str_; };

---

MaClass.cpp

Code:

---

1 2 3 4 5 6 7 8 9

#include <MaClass.h> #include <string> MaClass::MaClass(char* str):str_(new std::string) { } MaClass::~MaClass() { delete str_; }

---

NOTA: std::string étant en réalité un typedef de std::basic_string<...> spécialisé pour manipuler des char_t, il n'est pas exclu qu'il faille ruser un peu plus que cela ;)

Je ne pense pas que votre solution marche ( bon je devrais peut être testé avant de dire n'importe quoi ).

Mais dans votre MaClass.h , le std::string ( même s'il est déclaré avec anticipation ) n'est pas un pointeur ( ou référence ) donc le compilateur va raler.

Mais je veux pas de pointeur, ni de référence , à cause que pour une string, je veux pas m'embeter à faire de la gestion de mémoire. :D

Sinon, je n'ai pas dit que mon problème avait une réponse ... ( peut être encore moins d'utilité ). C'est juste que normalement, il faut éviter les include dans les fichiers d'entête.
Ceci m'aurait permis, que si j'inclut mon fichier MaClass.h dans un autre, je ne veux pas que l'autre fichier est accès aux fonctions des string.
( Ce qui est aussi pour les vector, les map, et tout les autres truc que j'utilise de la STL ).

( Merci pour la réponse rapide :) )

C'est surtout parce que j'ai oublié l'étoile (tellement peu l'habitude de déclarer un pointeur de type std::string qu'elle est restée dans mon clavier) :aie:

Je corrige le code en conséquence ;)

Moi aussi j'aurais fait la même erreur :D
Du coup, je suppose qu'il n'y ai pas de solution à ce que je veux faire ... sans mettre la std::string en pointeur ...

Citation:

---

Envoyé par LittleWhite

Moi aussi j'aurais fait la même erreur :D
Du coup, je suppose qu'il n'y ai pas de solution à ce que je veux faire ... sans mettre la std::string en pointeur ...

---

Je n'en vois pas vraiment...

A moins de déclarer str_ (selon l'exemple) sous la forme d'une référence, mais cela implique... qu'il faille garder la chaine "originelle" "quelque part"... et, par conséquent, veiller à ce que la chaine originelle ne soit pas détruite tant qu'il y a un objet qui la référence :aie:

Voilà qui risque de compliquer considérablement le desing re :aie:

Bon bah j'abandonne mon idée ( de toute façon, c'était pas très grave ).
Merci pour vos réponses ( très rapides ).
Bonne fin d'après midi :).