Discussion :

[Tymk]

Salut,

J'ai une classe B qui derive d'une classe A et qui possede 2 constructeurs. Le constructeur par defaut appelle le constructeur parent (celui de A) alors que l'autre constructeur n'appelle rien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
class A{
    A();
};
 
class B : public A{
    B();
    B(int i);
};
 
B::B() : A(){}
 
B::B(int i){}

Lorsque je fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

B *b = B(14);

J'ai l'impression que le constructeur de A est quand meme appele.

Est-ce que ca vient du fais que le contructeur par defaut est toujours appele (et qu'il appelle lui meme le constructeur parent) ?
Est-ce que ca vient du fais que le contructeur parent est toujours appele ?
Est-ce que je fabule ?

Merci de m'apporter vos lumieres

[Davidbrcz]

Ca vient du fait qu'un constructeur de la classe parente est toujours appelé.
Après, faut voir lequel tu veux appeler (ca peut être celui par défaut, comme un autre), ca ne dépend que de toi. Mais sache que par défaut, c'est le constructeur par défaut qui est appelé (logique non ? )

PS: remplace ton constructeur par défaut pas un constructeur attendant un argument et ton code ne compile plus.

[Tymk]

Donc, la solution c'est de creer un constructeur A(int i) qui ne fait rien et de l'appeler explicitement ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

B::B(int i) : A(i){}

[JolyLoic]

La solution, c'est tout d'abord de comprendre pourquoi tu voudrais qu'un objet de type B n'initialise pas sa sous partie de type A. Ca sent l'héritage qui n'aurait pas dû avoir lieu... Peut-être pourra-t-on mieux t'aider si tu nous explique ta problématique (et pas avec des noms comme A et B).

[Alp]

La solution, c'est tout d'abord de comprendre pourquoi tu voudrais qu'un objet de type B n'initialise pas sa sous partie de type A. Ca sent l'héritage qui n'aurait pas dû avoir lieu... Peut-être pourra-t-on mieux t'aider si tu nous explique ta problématique (et pas avec des noms comme A et B).

On dirait, oui.

Tymk > est-ce que tout s'arrange si tu mets 'A' en attribut de B, via une instance statique, un pointeur vers A ou autre ?

[Noxen]

J'ai l'impression que le constructeur de A est quand meme appele.

Une classe mère sert de base, de fondation à une classe fille. Le constructeur d'une classe fille appelle toujours un constructeur de la classe mère (bien que tu puisses spécifier lequel). Sinon, ce serait comme vouloir faire le premier étage d'un immeuble mais pas le rez-de-chaussée !

[Tymk]

Sinon, ce serait comme vouloir faire le premier étage d'un immeuble mais pas le rez-de-chaussée !

En l'occurence, c'est exactement ce que je veux faire...

Les classes SOCKET_TCP_CLIENT et SOCKET_TCP_SERVER derivent toutes les 2 de SOCKET_TCP.

SOCKET_TCP appelle dans son constructeur par defaut la methode create_socket() qui cree un socket en mode TCP. En fonctionnement normal, les classes SOCKET_TCP_CLIENT et SOCKET_TCP_SERVER doivent donc appeler ce constructeur.

Neanmoins, le SOCKET_TCP_SERVER appelle la fonction accept() qui cree un socket de type client. J'ai donc declare dans ma classe SOCKET_TCP_SERVER un pointeur vers une instance de SOCKET_TCP_CLIENT. Je recupere le descripteur de socket retroune par accept() et je definie cette instance par l'appel d'un constructeur SOCKET_TCP_CLIENT(int desc_sock).

Le constructeur SOCKET_TCP_CLIENT(int desc_sock) ne doit surtout pas appeler le constructeur SOCKET_TCP(). Sinon, ce dernier cree un socket qui ne sert a rien puisque accept() a deja cree le socket client.

Pour le moment, ce socket inutile est cree. Au regard de ces informations, est-ce que creer un constructeur A(int i) qui ne fait rien et l'appeler explicitement est une solution viable ?

Tymk > est-ce que tout s'arrange si tu mets 'A' en attribut de B, via une instance statique, un pointeur vers A ou autre ?

Arf, j'ai pas encore les accreditations suffisantes pour acceder a ce vocabulaire technique. Est-ce grave ?

[JolyLoic]

J'ai l'impression après avoir fait une lecture rapide que ce dont tu as besoin, au niveau de la classe da base, c'est bien de 2 constructeur, mais le second ne serait pas un constructeur bidon, mais un constructeur qui prenne en paramètre une socket existante et la stocke comme étant sa socket.

Une alternative pourrait être de dire que SOCKET_TCP ne crée jamais la socket dans son constructeur (c'est bien une classe abstraite ?) mais fournit juste à ses dérivées les points d'entrée pour le faire s'ils en ont besoin.

[Tymk]

J'ai l'impression après avoir fait une lecture rapide que ce dont tu as besoin, au niveau de la classe da base, c'est bien de 2 constructeur, mais le second ne serait pas un constructeur bidon, mais un constructeur qui prenne en paramètre une socket existante et la stocke comme étant sa socket.

C'est deja ce que je fais au niveau de SOCKET_TCP_CLIENT.
J'ai un constructeur par defaut qui appelle le constructeur parent et ce dernier cree le socket.
J'ai un constructeur qui prend un descripteur de socket et qui l'affecte au descripteur de socket membre de la classe. (et qui normalement n'appelle pas le constructeur parent pour eviter la creation d'un socket en trop).

Mais, il serai effectivement plus judicieux de definir le fonctionnement du constructeur SOCKET_TCP_CLIENT(int) dans un constructeur parent SOCKET_TCP(int). Meme si ce constructeur parent n'a aucun interet pour la classe SOCKET_TCP_SERVER qui en derive. C'est toujours mieux que de mettre un constructeur bidon.

Une alternative pourrait être de dire que SOCKET_TCP ne crée jamais la socket dans son constructeur (c'est bien une classe abstraite ?) mais fournit juste à ses dérivées les points d'entrée pour le faire s'ils en ont besoin.

SOCKET_TCP est une classe abstraite qui ne contient que la methode create_socket() (et d'autres fonctions virtuelles pures). Il est important que cette methode soit definie dans SOCKET_TCP car elle est commune aux 2 classes derivees SOCKET_TCP_CLIENT, SOCKET_TCP_SERVER.

Edit : En plus, je trouve qu'une classe ne contenant que des methodes virtuelles pures n'a pas vraiment d'interet.

[Noxen]

(et qui normalement n'appelle pas le constructeur parent pour eviter la creation d'un socket en trop).

Si !! Même si tu ne définis pas de constructeur, le compilateur va générer un constructeur implicite. Même si ton constructeur "ne fait rien", il sera quand même appelé. Création d'objet = appel au constructeur (enfin, on ne parlera pas du placement new ici). Il faut vraiment comprendre que l'objet de la classe fille est créé "autour", ou "sur", de l'objet de la classe mère. D'ailleurs, par rapport au polymorphisme, le constructeur ne peut PAS être déclaré virtual, toute création d'objet passe par la création ascendante (classe mère vers classe fille) des composants de l'objet.

C'est toujours mieux que de mettre un constructeur bidon.

Rien ne t'empêche de créer un constructeur qui n'effectue aucun traitement. Il peut même être nécessaire de définir explicitement un constructeur non-paramétré (du moins, si ça a un sens), même s'il ne fait rien de spécial. Notamment, si tu définis un constructeur paramétré, mais pas de constructeur non-paramétré, le compilateur va considéré que cet objet DOIT être créé avec des paramètres (je suppose que ce doit être une histoire de masquage), tu ne peux plus créer d'objet de ta classe sans lui donner de paramètre. C'est important, parce-que par exemple tu ne pourras plus créer de tableau d'objet, puisque la création du tableau suppose la création d'objets, auxquels tu ne donnes pas de paramètres.

Edit : En plus, je trouve qu'une classe ne contenant que des methodes virtuelles pures n'a pas vraiment d'interet.

C'est ce qu'on appelle une interface. Une interface ne définit normalement pas de traitements. Son rôle est de présenter une liste de services, que devront implémenter toutes les classes qui sont sensées respecter cette interface.

Par exemple : supposons que tu fasses une application qui gère des données, ces données devant ensuite être stockées dans un fichier xml, et donc respectant un formatage xml. Cela signifie que tout les objets qui seront transmis au, et manipulés par, le gestionnaire de données dans ton application devront être capable de fournir au gestionnaire une chaîne de caractères contenant ses données, formatées pour respecter un schéma xml ; peut importe comment ils créent cette chaîne, la seule chose qui compte est qu'ils la donnent au moment où on la leur demande.

Tu vas créer une interface :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
class ISerializable
{
public:
    virtual std::string ToXML() const = 0 ;
};

et tous les objets qui seront transmis devront hériter de cette interface et devront fournir une réponse à un appel à ToXML().

Si quelque chose te semble ambigüe, n'hésite pas à demander