constructeur avec paramètres et classe dérivées

J'ai une classe de base (A) dont le seul constructeur qui existe est un constructeur prenant un attribut, disont une std::string qui est son nom. J'aimerai que toutes ces classe dérivées (A1, A2, ....)facent de même. Est-ce possible de faire quelquechose dans la classe de base pour les obligés à le faire ?
En d'autre terme j'aimerai éviter quequelqu'un fasse cela:

Code:

---

1 2 3 4

class A1: public A { A1():A("pas de nom"){}; };

---

Le constructeur par défaut de A1 existe et peut être utilisé, ce que je voulais éviter.
En plus le constructeur de A1 prenant une std::string n'existe pas ce que je voulait éviter aussi.

Citation:

---

En plus le constructeur de A1 prenant une std::string n'existe pas ce que je voulait éviter aussi.

---

Tu ne peux le spécifier, une personne qui créer une class A3 pour hériter de A peut faire ce qu'elle veut dans ces constructeurs ! (je ne vois pas de méthode pour l’empêcher de faire des constructeurs)

Citation:

---

J'ai une classe de base (A) dont le seul constructeur qui existe est un constructeur prenant un attribut

---

Tu as bien déclaré en private le constructeur de A par défaut ?

Code:

---

1 2 3 4

private: A(); // car celui ci est construit même si tu ne le déclares pas ! public: A(String _toto);

---

Je pense que déclarer dans A un constructeur privé prenant en paramètre un const char* pourrait aider. Mais en partie seulement, car cela n'empêchera pas les classes dérivées d'utiliser un std::string. Mais ça devrait limiter déjà toute utilisation de chaîne littérale.

Citation:

---

A(); // car celui ci est construit même si tu ne le déclares pas !

---

Non, pas s'il y en a un autre ;)

merci pour vos réponses, même si c'est celles que je craignai.
Vous avez des idées de pourquoi c'est comme ça ?
Je veut dire pourquoi on peut imposer à une classe fille l'implémentation d'une méthode (utilisation de méthodes virtuelle pure dans la classe de base), mais que l'on ne puisse rien faire sur les constructeurs ?
Il y certainement une raison logique, mais elle m'échappe.

Autant l'appel de fonctions héritées est super important, autant l'appel d'un constructeur ne l'ai pas.

Ce qu'on souhaite avec l'héritage c'est que les fonctions puissent être appelées, le constructeur le sera aussi, mais cela à une moindre importance sur le comment.

Citation:

---

Citation:

---

A(); // car celui ci est construit même si tu ne le déclares pas !

---

Non, pas s'il y en a un autre

---

J'avais oublié :oops:

Je pensais qu’il faisait partie de la liste constructeur par copie/destructeur/constructeur operateur =

Oui, il y a une raison logique.
Les methodes, opérateurs et destructeurs ce sont moultes trucs qui peuvent potentiellement être redéfinis dans une classe fille. D'où le fait que la classe mêre aie une influence la dessus (attention qu'elle ne peut "empecher" une classe fille d'avoir plus de possibilités, si ce n'est par un élément de syntaxe tordu). Le constructeur c'est différent: il faut connaitre le nom de ta classe pour l'instancier, d'où le fait qu'il soit spécifique à une classe et pas ses dérivées.
De toutes façon, je te déconseille de vouloir absolument faire des classes sans constructeur par défaut. Ca a l'air interessant comme ca mais on se rend compte à la longue que ca devient énervant.

non malheureusement, tu ne peux pas empecher quelqu'un de modeler sa propre classe, elle lui appartient (meme si elle dérive de la tienne).

ce que tu peux faire, c'est uniquement de restreindre l'acces à TA classe, donc en ne définissant qu'un seu constructeur (pourquoi pas avec un attribut "explicit"). tu peux également mettre le constructeur en protected (pas private) pour que ta classe soit abstraite et force à etre dérivée, mais la encore, tu ne pourras pas empécher l'architecte de créer un constructeur sans parametre sur la classe fille.

une question cela dit :
pourquoi la classe qui héritera de la tienne ne peut pas définir un constructeur saus parametre et appeler le tient en passant la bonne string ? (si c'est le comportement que la classe fille doit avoir :? )

Citation:

---

Envoyé par zais_ethael

De toutes façons, je te déconseille de vouloir absolument faire des classes sans constructeur par défaut. Ca a l'air interessant comme ca mais on se rend compte à la longue que ca devient énervant.

---

J'ai tendance à partir dans l'autre direction : pas de constructeur par défaut, pas de mutateur trivial.
Cela limite les abus du genre

Code:

---

1 2	T v; v = f();

---

écris sur deux lignes évidemment séparées de 10 autres sans rapport.

Citation:

---

Envoyé par toxcct

une question cela dit :
pourquoi la classe qui héritera de la tienne ne peut pas définir un constructeur saus parametre et appeler le tient en passant la bonne string ? (si c'est le comportement que la classe fille doit avoir :? )

---

C'est une bonne question ça ;)
Pour de mauvaise raisons je suppose. En fait dans ma classe mère j'ai mis un attribut qui doit absoluement être rempli. Mais comme son utilité n'est pas visible au premier coup d'oeil et que je sais qui va produire les classes dérivées; je sens bien que cetains architectes vont me mettre un valeur en dur comme ça dans leur code. Et avec des tests sommaires ils auront l'ipression que cela marche et puis il vont livrer mettre enb prod et quand le bug aparaitra ce sera trop tard. Il vont venir me voir en disant:"ton truc y marche pas" alors je leur ferai remarqué qu'ils on fait un truc déconseillé dans la doc. Et ils vont me dire, comme d'hab, "j'ai pas sle temps des les lires tes doc."
Vous le dites si j'étalle un peu trop ma vie.:aie:

si les docs sont écrites, tu es a l'abri. mais tu as peut etre bien aussi un probleme de design a repenser... ;)

cela dit, je ne visualise toujours pas le réel pb... lol

Citation:

---

Envoyé par toxcct

si les docs sont écrites, tu es a l'abri. mais tu as peut etre bien aussi un probleme de design a repenser... ;)

cela dit, je ne visualise toujours pas le réel pb... lol

---

Les docs seront écrites, mais je suis à l'abri qu'en théorie, en pratique je sais bien que les gens ne les lisent pas, mais bon là on peu rien y faire.
Si tu ne visualise pas le réel problème alors c'est que je doit mal l'expliquer.

Je n'ai parcouru que très rapidement, mais faire d'une factory le seul moyen de création de tes classes, et spécifier que les fonctions de création gérées par cette factory prennent ce paramètre pourrait être une voie...

Mais cela ne résoud pas le problème de l'héritage s'il tient véritablement à ne pas permettre aux constructeurs dérivés de lever une variabilité à la construction, et que la dérivation doit être autorisée.

En supposant qu'il soit possible de forcer la demande d'un paramètre dans les classes dérivées, rien n'empêche un utilsateur de créer une fonction pour instancier des objets avec des paramètres par défaut.

Le problème me semble donc insoluble.

Quoique : si la classe mère détecte que les arguments qu'elle reçoit sont incorrects, alors elle peut lancer une exception pour éviter que les utilisateurs de la classe aient "l'impression que cela marche" (une classe qui continue à fonctionner sans rien dire alors qu'il y a un problème me semble un peu dangereuse).

Citation:

---

Envoyé par boromir73

Quoique : si la classe mère détecte que les arguments qu'elle reçoit sont incorrects, alors elle peut lancer une exception pour éviter que les utilisateurs de la classe aient "l'impression que cela marche" (une classe qui continue à fonctionner sans rien dire alors qu'il y a un problème me semble un peu dangereuse).

---

une sorte de prog défensive quoi. Je n'y avait pas pensé et faute de mieux je vais faire ça.
Merci à tous pour vos réponses !