Discussion :

[koala01]

Bonjour,

Dans le cadre de l'apprentissage des bases de C++, je cherche à répondre le probleme suivant, qui ne doit pas présenter de difficultés particulières je pense mais je suis novice et c'est pas facile au départ.
Auriez vous svp des éléments de réponses à apporter?
Merci par avance!

Soit la classe C++ suivante :

Code :

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

1
2
3
4
5
6
7
8
Class Contenu 
{ 
Public : int x ; 
int y ; 
Contenu() {} ;// le contenu des fonctions n’a pas été défini et donc ne peut // être considéré comme étant une erreur de syntaxe 
int Execute() {} ; 
void Print() {} ; *
} ;

Questions :

1 – Cette classe vous semble-t-elle correcte syntaxiquement ?

Syntaxiquement, oui... elle sera acceptée à la compilation

2 – La notion d’encapsulation au sens C++ est – elle présente dans cette classe ? Justifiez dans les 2 cas (oui ou non) votre réponse. Au cas où il n’y a pas d’encapsulation dans cette classe, proposez la mise en oeuvre de cette notion au sein de cette classe.

L'encapsulation consiste à faire en sorte que l'utilisateur de la classe n'ai pas d'accès au "détails d'implémentation" de celle-ci... qu'en penses-tu

1)Si on definit les fonction en même temps que la déclaration on doit mettre le nom de la classe avant la déclaration, public c'est sans majiscule donc vous aurez:

Code :

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

1
2
3
4
5
6
7
8
Class Contenu 
{ 
public : int x ; 
int y ; 
Contenu::Contenu() {} ;// le contenu des fonctions n’a pas été défini et donc ne peut // être considéré comme étant une erreur de syntaxe 
int Contenu::Execute() {} ; 
void Contenu::Print() {} ; *
} ;

Quelle horreur... justement pas...

Tu peux définir une fonction (qui sera considérée implicitement comme inline) directement au sein de la définition de la classe sans préciser que... tu définis effectivement une fonction membre de la classe...

Mais le fait que la fonction soit implicitement considérée comme inline place certaines restrictions (entre autres au niveau des fonctions virtuelles)

C'est lorsque, justement, tu ne définis pas les fonctions membres au sein de la définition de la classe que tu dois préciser la portée complete sous la forme de

Code :

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

1
2
3
4
<type de retour> <nom de la classe>::<nom de la fonction>(<liste d'arguments>) <cv-qualifier de la fonction>
{
    <corps de la fonction>
}

3)On peut hériter de n'importe quel classe donc cette classe peut être une classe de base dans le cas de l'héritage sauf que pour les classes vraiment de base on utilise plus des classe abstraite

encore une fois NON...

du moins, pas dans l'optique d'un héritage public, avec la notion polymorphe qu'il entraine.

En effet, si tu a le malheur de faire passer un objet de la classe dérivée pour la classe de base telle qu'elle est décrite ici et de détruire l'objet en question, seul le destructeur de la classe de base sera appelé, les membres propres aux classes dérivées ne seront donc pas détruit, et tu t'orientes tout droit vers... de fantastiques fuites mémoire... dans le meilleur des cas.

En effet, lorsque le compilateur ne rencontre pas de déclaration du constructeur, il en place un "par défaut" qui

1. est public
2. est inline
3. est non virtuel
4. appelle le destructeur des membres dans l'ordre inverse de leur déclaration

Un tel destructeur ne respecte pas le minimum requis pour une utilisation polymorphe

6)Pour que la classe devienne abstraite on met dans la declaration apès le nom de la classe abstract et on definit aucune methode et on ajoute virtual avant le type de retour des methodes pour les attributs ils doivent etre protected pour permettre leur heritage. Cela implique qu'on ne peut pas instancier d'objet directement de cette classe elle est utilisée seulement comme classe de base pour d'autre classe

Là aussi, j'ai l'impression que tu t'es trompé de langage...

Le mot clé abstract n'existe pas en C++

Pour qu'une classe soit considérée comme abstraite, il "suffit" qu'une des fonctions membres soit virtuelle pure.

Toute classe dérivant d'une classe abstraite et ne redéfinissant pas la fonction virtuelle pure sera elle aussi considérée comme une classe abstraite

[3DArchi]

Salut,
Puisque cette question de type 'faites mes devoirs' sollicite beaucoup de réaction, profitons en pour chipoter un peu

Syntaxiquement, oui... elle sera acceptée à la compilation

Telle que l'a écrite le posteur, il y a des erreurs de casses (Class/class, Public /public,) un '*' qui traine à la fin de la fonction Print. Les ';' après les définitions de fonction, là j'avoue que je ne sais pas si c'est syntaxiquement autorisé. gcc dit rien en mode ansi+pedantic et visual non plus.
Pour les problèmes de casses et pour le '*', la réponse est non. Mais, comme je l'ai dit et comme l'a souligné Luc : UTFC. Ce sont typiquement (et tu en fais involontairement la preuve) des erreurs que l'on fait tous les jours, qu'on ne trouve pas forcément en relecture ... et que le compilateur trouve très bien pour nous. Donc, c'est complètement stupide (du moins c'est mon avis) de poser ce genre de question en exam.

L'encapsulation consiste à faire en sorte que l'utilisateur de la classe n'ai pas d'accès au "détails d'implémentation" de celle-ci... qu'en penses-tu

Voilà typiquement le genre de question qui me parait dénuée de sens lorsqu'elle prise en dehors de tout contexte : x et y sont-ils des détails d'implémentation ou des 'services triviaux' de la classe Contenu ? std::pair a les membres first et second en public et pourtant personne ne pense que l'encapsulation est brisée. Il en est peut être de même pour Contenu et x et y...
[mode capilotracté] D'ailleurs, toutes les fonctions de Contenu sont définies et aucune d'entre elles n'utilise ni x ni y. Donc x et y ne sont pas des détails d'implémentation mais des bien des services offerts par Contenu. Donc la réponse est oui : l'encapsulation est respectée.
[/mode capilotracté]

Mais le fait que la fonction soit implicitement considérée comme inline place certaines restrictions (entre autres au niveau des fonctions virtuelles)

Je précises que le lien entre fonctions virtuelles et fonctions inline se résume dans la phrase : les fonctions virtuelles ne peuvent être expansées par le compilateur lorsque l'appel implique une résolution dynamique. C'est la seule restriction. Dans tous les autres cas, il n'y a pas de problème. Entre autres, une fonction virtuelle peut être expansée en ligne si l'appel peut être résolu statiquement (par expl, dans le constructeur/destructeur ou si l'appel se fait avec une variable par valeur)

du moins, pas dans l'optique d'un héritage public, avec la notion polymorphe qu'il entraine.

En effet, on pourrait répondre à la normande :
-> oui si l'héritage est privé,
-> non si l'héritage est public.
mais comme dit précédemment, cette question n'a aucun sens si on la prend dans une optique strictement syntaxique.

seul le destructeur de la classe de base sera appelé

Pour continuer dans le chipotage, en fait, le comportement est indéterminé. Donc, ça pourra faire ce que tu dis ... ou bien faire le café

En effet, lorsque le compilateur ne rencontre pas de déclaration du constructeur, il en place un "par défaut" qui

lire destructeur


@Slash86,@Bnj1391,@xuantran : si vous pouvez indiquer à votre prof de venir faire un tour ici, je serais assez curieux de sa justification à ces questions. Car :
1/ Ne montre en rien la connaissance ou non du langage ni de sa syntaxe.
2/ Parler de respect ou non de l'encapsulation présuppose qu'on définit d'abord ce que propose la classe comme service. Ensuite on montre son code. Et là on regarde s'il y a des trucs 'visibles' qui ne devraient pas. En dehors de tout contexte, cette question n'a pas de sens.
3/Idem : sans contexte sémantique, cette question ne peut avoir de réponse consensuelle.
4/ Comment a-t-il été défini en cours ? Si c'est tel que nous le dit Slash86, alors là, effectivement vous êtes mal barré.
7/ Je comprend même pas la question si ce n'est qu'on sent bien que le prof veut des exemples de générique.

[Luc Hermitte]

1) Pour les gens soucieux de la déontologie, rassurez-vous, vous n'avez pas donné les réponses à un genre de "devoir maison" et offert gratuitement une bonne note à un noob, en effet, il s'agit juste d'une anale non corrigée en vue d'un examen

2) Finalement, même si ca se fait pas de poser des question brutes comme ca, au moins il faut admettre que ca semble vous avoir fait réfléchir puisque vous semblez n'être pas tous d'accord !
Allez, il faut avouer qu'un peu de réflexion sur les principes théoriques ne fait pas de mal de temps en temps (Bon je dis ca ... mais si seulement j'y comprenais quelque chose ... :s )

1) Ouais, mais bon, vous donner la réponse sans que vous n'ayez pris la peine d'y réfléchir préalablement ne va nullement vous aider à mieux réussir votre exam.

2) La communeauté C++ aime beaucoup pinailler. Ce n'est pas une question de réfléchir ou de ne pas être d'accord, car au fond avec 3DArchi et Koala, nous en savons autant sur ces sujets.

Mais comme le dit, encore, 3DArchi, c'est le contexte qui fait tout. Et suivant le contexte d'étude, la réponse donnée sera différente. D'où les réponses apparemment différentes : nos différences de sensibilité font que par défaut on se place tous dans des contextes subtilement différents.

Pour la définition du polymorphisme, il est clair que les définitions inexploitables, qui se veulent synthétiques, hantent les étudiants et la toile. De temps en temps on en croise une jolie, qui veut dire quelque chose, et qui est juste. (Merci à Jean-Marc pour celle que nous avons dans la FAQ.)

PS: les questions de l'exo me font dire que votre prof sait qu'il n'existe pas que le polymorphisme d'inclusion. Et pourtant la définition me donne l'impression qu'il ne connait que celle-ci.