[Newbie] Constructeur et héritage

Le
TSalm
Bonjour,

J'hérite de la classe std::string, mais je ne spécifie pas de
constructeurs dans ma classe fille.

Mon compilateur refuse alors allégrement un
ExtString("bla bla bla");
En me répondant que le constructeur n'existe pas
Est-elle impossible d'hériter implicitement des constructeurs des
classes parentes ?
Dois-je vraiment respécifier tout les constructeurs ?

d'avance merci pour votre aide,
TSalm

Exemple pour illustrer mon probléme :
//-CODE
#include <iostream>
#include <string>

using namespace std;

class extString: public string {
public:
// extString(char * c) : string(c) {
// cout << "construct" << endl;
// }

int getSomething() {
return 12;
}
};

int main()
{
extString s("hello");
cout << s.getSomething() << endl;
return 0;
}
//FIN CODE-
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sylvain
Le #307739
TSalm wrote on 07/06/2007 00:29:

J'hérite de la classe std::string, mais je ne spécifie pas de
constructeurs dans ma classe fille.

Mon compilateur refuse alors allégrement un
ExtString("bla bla bla");
En me répondant que le constructeur n'existe pas...


puisqu'il n'existe pas ...

Est-elle impossible d'hériter implicitement des constructeurs des
classes parentes ?


non.

Dois-je vraiment respécifier tout les constructeurs ?


non ... seulement ceux que tu souhaites utiliser.

Sylvain.

Alain Gaillard
Le #307737
Dois-je vraiment respécifier tout les constructeurs ?


non ... seulement ceux que tu souhaites utiliser.



Mais est-ce même une bonne idée de dériver std::string qui n'a pas de
destructeur virtuel ? En règle générale les classes de la STL et
l'héritage ne font pas bon ménage. AMHA ici la composition est plus
pertinente que l'héritage. Autrement dit il serait mieux que ExtString
détienne un membre de type std::string.


--
Alain


TSalm
Le #307712
TSalm wrote on 07/06/2007 00:29:

J'hérite de la classe std::string, mais je ne spécifie pas de
constructeurs dans ma classe fille.

Mon compilateur refuse alors allégrement un
ExtString("bla bla bla");
En me répondant que le constructeur n'existe pas...


puisqu'il n'existe pas ...

Est-elle impossible d'hériter implicitement des constructeurs des
classes parentes ?


non.

Dois-je vraiment respécifier tout les constructeurs ?


non ... seulement ceux que tu souhaites utiliser.



merci, ça a au moins le mérite d'être bref et clair ... je sens que
j'ai posé une question idiote ;-)


TSalm
Le #307711

Dois-je vraiment respécifier tout les constructeurs ?




Mais est-ce même une bonne idée de dériver std::string qui n'a pas de
destructeur virtuel ? En règle générale les classes de la STL et
l'héritage ne font pas bon ménage. AMHA ici la composition est plus
pertinente que l'héritage. Autrement dit il serait mieux que ExtString
détienne un membre de type std::string.


Mais je perdrais du même coup toute les méthodes inhérentes à la
classe string (suis je le seul fainéant qui ne veut pas implémenter
les méthodes et les constructeurs implicitement ? :) )

TSalm



Fabien LE LEZ
Le #307710
On Thu, 07 Jun 2007 22:35:48 +0200, TSalm
Mais je perdrais du même coup toute les méthodes inhérentes à la
classe string


Oui.
Mais si tu crées une nouvelle classe, c'est parce que ce que fait
std::string ne te convient pas, non ?

Sylvain
Le #307709
TSalm wrote on 07/06/2007 22:21:

merci, ça a au moins le mérite d'être bref et clair ... je sens que
j'ai posé une question idiote ;-)


question peut être un peu idiote sur la forme mais pas sur le fond.

Alain et Fabien ont bien résumé les problèmes liés à l'héritage de
classe de la STL, puisqu'elles ne s'y prêtent pas.

reste soit à hériter statiquement en étendant le template réutilisé
(sûrement des limites, je n'ai que peu essayé) ou à agréger ... si
vraiment les services repris valent le coup.

cette vision revient à considérer la STL avant tout comme des classes
utilitaires, en cela on se refuse à exporter, hériter publiquement, etc,
des classes STL, mais on les utilise seulement dans le corps des
méthodes bénéficiant de leurs services via des instances locales ou des
instances agrégées, protégées / privées - je me contente de cela.

Sylvain.

Vianney Lançon
Le #307708
On 7 juin, 00:36, Sylvain
TSalm wrote on 07/06/2007 00:29:



J'hérite de la classe std::string, mais je ne spécifie pas de
constructeurs dans ma classe fille.




Est-il besoin d'ajouter des données membre dans la classe dérivée?
Sinon, si l'on veux juste ajouter des fonctions
de maniplation de chaine de caractères, vouloir hériter de std::string
n'est sans doute pas la meileur solution.

Dans le cas de std::string où il n'y a que rarement le besoin
d'accéder à des données privées
des fonctions libres suffisent le plus souvent.

namespace StringUtils {
void replace(std::string& str, const std::string& before, const
std::string& after);
bool split(const std::string& str, const std::string& sep,
std::vector<std::string>& out);
std::string toUpper(const std::string& str);
int getSomething(const std::string& str)
}

Sutter fait un article argumenté dessus: <Monoliths "Unstrung">
http://www.gotw.ca/gotw/084.htm


Est-elle impossible d'hériter implicitement des constructeurs des
classes parentes ?


non.




Vianney Lançon
Le #307707
On 7 juin, 00:29, TSalm
Bonjour,

J'hérite de la classe std::string, mais je ne spécifie pas de
constructeurs dans ma classe fille.

Dois-je vraiment respécifier tout les constructeurs ?




Est-il besoin d'ajouter des données membre dans la classe dérivée?
Sinon, Si on veux juste ajouter des fonctions
de maniplation de chaine de caractères, vouloir hériter de std::string
n'est sans doute pas la meileur solution.

Pour le cas de std::string où il n'y a que rarement le besoin
d'accéder à des données privées
des fonctions libres suffisent le plus souvent.

namespace StringUtils {
void replace(std::string& str, const std::string& before, const
std::string& after);
bool split(const std::string& str, const std::string& sep,
std::vector<std::string>& out);
std::string toUpper(const std::string& str);
}

Sutter fait un article argumenté dessus: <Monoliths "Unstrung">
http://www.gotw.ca/gotw/084.htm

TSalm
Le #307706
Le Thu, 07 Jun 2007 23:41:12 +0200, Fabien LE LEZ

On Thu, 07 Jun 2007 22:35:48 +0200, TSalm
Mais je perdrais du même coup toute les méthodes inhérentes à la
classe string


Oui.
Mais si tu crées une nouvelle classe, c'est parce que ce que fait
std::string ne te convient pas, non ?


Oui et non, j'aurais voulu AJOUTER des fonctionnalitées
supplémentaires.


TSalm
Le #307705
Le Fri, 08 Jun 2007 00:13:17 +0200, Sylvain :

TSalm wrote on 07/06/2007 22:21:

merci, ça a au moins le mérite d'être bref et clair ... je sens que
j'ai posé une question idiote ;-)


question peut être un peu idiote sur la forme mais pas sur le fond.

Alain et Fabien ont bien résumé les problèmes liés à l'héritage de
classe de la STL, puisqu'elles ne s'y prêtent pas.

reste soit à hériter statiquement en étendant le template réutilisé
(sûrement des limites, je n'ai que peu essayé) ou à agréger ... si
vraiment les services repris valent le coup.

cette vision revient à considérer la STL avant tout comme des classes
utilitaires, en cela on se refuse à exporter, hériter publiquement, etc,
des classes STL, mais on les utilise seulement dans le corps des
méthodes bénéficiant de leurs services via des instances locales ou des
instances agrégées, protégées / privées - je me contente de cela.

Bon, j'ai des lacunes en ce qui concerne les destructeurs virtuels que

je vais combler de ce pas.

Merci à tous.


Publicité
Poster une réponse
Anonyme