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;
// }
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
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
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.
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
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 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 ;-)
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
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
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 ? :) )
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
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 ?
On Thu, 07 Jun 2007 22:35:48 +0200, TSalm <tsalm@free.fr>:
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 ?
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
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.
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.
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
On 7 juin, 00:36, Sylvain wrote:
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.
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.
On 7 juin, 00:36, Sylvain <noS...@mail.net> wrote:
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.
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.
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
On 7 juin, 00:29, TSalm wrote:
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.
Sutter fait un article argumenté dessus: <Monoliths "Unstrung"> http://www.gotw.ca/gotw/084.htm
On 7 juin, 00:29, TSalm <t...@free.fr> wrote:
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.
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.
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 Fri, 08 Jun 2007 00:13:17 +0200, Sylvain a écrit :
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.
Le Fri, 08 Jun 2007 00:13:17 +0200, Sylvain <noSpam@mail.net> a écrit
:
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
Le Fri, 08 Jun 2007 00:13:17 +0200, Sylvain a écrit :
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
