petites questions toutes simple pour débutant C++

je suis nouveau ici et j'ai besoin d'aide les gas

des question pour test C++
Q1: Je suis un autre nom que l'on peut donner à une donnée membre, je suis ......
Q2: Je suis le principe selon lequel un objet est responsable de ses données et doit en contrôler l'accès, je suis .....
Q3: Je suis une forme d'héritage qui permet à une instance d'une classe enfant de faire appel à une méthode du parent, je suis .......
Q4: Je suis une forme d'héritage qui permet à un enfant d'avoir plusieur parents, je suis ......
Q5: Je suis le mécanisme qui permet, à travers une méthode disponible dans la classe ancêtre, de faire appel à une méthode spécifique d'une classe enfant, je suis .....
Q6: Je suis une classe qu'on ne peut instancier bien que mon constructeur soit public, je suis une classe......................

Merci pour votre aide

Q1: un attribut
Q2: l'encapsulation (ou notion d'interfaces)
Q3: le polymorphisme
Q4: le multi-héritage l'héritage multiple
Q5: un patron de méthode ("template method pattern") (<- lien wiki français)
Q6: singleton ou usine

merci, j'ai d'autres questions suivantes :

Q1: Je suis un modèle qui décrit ce qui est commun à plusieurs instance, je suis la ...............
Q2: Dans une situation d'héritage simple et public, il y'a un cas ou une méthode publique de la classe parent, méthode publique qui n'est pas abstraite, ne pourra etres appelée par le biais d'une instance de la classe enfant. décrivez ce cas
Q3: À quelle condition une classe dérivée d'une classe abstraite peut-elle etres instanciée ?
Q4: Une interface abstraite opaque qui n'a pas pour but que de dévoiler les méthodes publiques d'une classe dérivée n'a pas à comporter de constructeur, pourquoi ?

Merci d'avance les amis(e) !

Attend d'autres réponses, je peux me planter :lol:

Q1: classe abstraite/ classe abstraite pure/ une interface
Q2: un destructeur
Q3: si toutes les méthodes abstraites pures ont été redéfinies
Q4: après recherche :mrgreen:, on me dit que l'on peut coder le pImpl avec une classe abstraite. Et donc classe abstraite, pas de pointeur, donc pas de constructeur -> :mrgreen:


Q4 - Source boost:
Another widely used C++ idiom for separating inteface and implementation is to use abstract base classes and factory functions. The abstract classes are sometimes called "interfaces" and the pattern is known as "interface-based programming". Again, shared_ptr can be used as the return type of the factory functions:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

// X.hpp:   class X { public:   virtual void f() = 0; virtual void g() = 0;   protected:   ~X() {} };   shared_ptr<X> createX();     // X.cpp:   class X_impl: public X { private:   X_impl(X_impl const &); X_impl & operator=(X_impl const &);   public:   virtual void f() { // ... }   virtual void g() { // ... } };   shared_ptr<X> createX() { shared_ptr<X> px(new X_impl); return px; }

---

A key property of shared_ptr is that the allocation, construction, deallocation, and destruction details are captured at the point of construction, inside the factory function. Note the protected and nonvirtual destructor in the example above. The client code cannot, and does not need to, delete a pointer to X; the shared_ptr<X> instance returned from createX will correctly call ~X_impl.

THX so much .....merci beaucoup :mrgreen::mrgreen::mrgreen::mrgreen::mrgreen::mrgreen:

Qa.3, "forme d'héritage qui permet à une instance d'une classe enfant de faire appel à une méthode du parent"
Le polymorphisme n'est pas une forme d'héritage. Après tous les héritages permettent d'appeler des fonctions membres des parents (que l'on découpe public/protégé/privé, ou implements/inherits), tant que la fonction membre parente n'est pas privée

Qa.4 On dit plutôt "héritage multiple" en VF

Qa.5 De nouveau formulation très floue, je pourrai caser polymorphisme, sous-typage, DP template method, NVI...

Qa.6 Nope. Un singleton est instaciable, une fois seulement, mais instanciable

Qb.1 Nope. Pas "commun à plusieurs classes", mais "commun à plusieurs instance"

Qb.2 Si, on peut appeler le destructeur explicitement (et tout faire planter)

Qb.3 En vocabulaire C++: si elle n'est plus abstraite. Et par définition une classe est abstraite si elle dispose de fonctions membre virtuelles pures -- qu'elles soient héritées et non supplantées, ou juste nouvellement virtuelles pures.

Qb.4 Il y a toujours une constructeur. Mais il n'est pas obligatoire qu'il soit public (typiquement pour les classes abstraites qu'un constructeur soit public ou protégé ne va rien changer). Pour les classes de collection de services (qui n'ont pas vocation à être détruites polymorphiquement), on peut même mettre des destructeurs protégés non virtuels.
Après, tant qu'une classe n'a pas à positionner des invariants non triviaux, il n'est pas nécessaire de lui définir explicitement un constructeur. On peut se contenter des constructeurs générés par défaut qui vont laisser les membres POD dans un état quantique non déterminé, et les autres membres construits avec leur constructeur par défaut.
Je ne vois pas trop ce que vient rajouter le contexte spécifié dans la question -- hormis impliquer qu'une interface bateau n'a pas de données, donc pas d'invariant positionnable à la construction, et de fait pas besoin d'expliciter un constructeur. Sauf qu'une interface va avoir un destructeur (public et virtuel), sa copie interdite (si, si, c'est nécessaire!), et donc des constructeurs deleted.

Citation:

---

Envoyé par Luc Hermitte

Qa.6 Nope. Un singleton est instaciable, une fois seulement, mais instanciable

---

C'est l'instance d'une donnée membre statique qui est retournée, mais la classe Singleton n'est pas forcément instanciable puisque tu peux utiliser une méthode statique. Comme l'usine.

Citation:

---

Envoyé par Luc Hermitte

Qb.1 Nope. Pas "commun à plusieurs classes", mais "commun à plusieurs instance"

---

Effectivement :mrgreen:, mais c'est juste une question de contexte

Citation:

---

Envoyé par Luc Hermitte

Qb.2 Si, on peut appeler le destructeur explicitement (et tout faire planter)

---

Effectivement :mrgreen:, mais jamais je n'ai vu quelque part un bout de code qui appelle un destructeur explicitement.
Donc, c'est bien ancré que destructeur == pas d'appel explicite (c'est automatique).
Contrairement à une méthode statique et/ ou constante, parce que j'ai pensé aussi à ces réponses.

Qa6. La seule chose non instanciable est une classe abstraite.
Par définition un singleton est instanciable au moins (et au plus) une fois. Donc il est instanciable. Que l'on utilise le pattern de Scott Meyers ou des new en interne.

Qb1. Le modèle commun à plusieurs instance est la classe :p

Qb2. On va le faire quand on sépare manuellement allocation et construction -- ce que l'on voit en interne des collections standard via std::allocator::destroy(). i.e., quand on utilise les new de placement.

Citation:

---

Envoyé par Luc Hermitte

Sauf qu'une interface va avoir [...] sa copie interdite (si, si, c'est nécessaire!), et donc des constructeurs deleted.

---

Une interface ne doit pas avoir de constructeur ou d'affectation de copie ou de mouvement avec la visibilité public, mais je pense qu'il est rarement pertinent de les interdire avec = delete. Personnellement, dans une interface, la majorité du temps, je mets les constructeurs et affectations de copie et de mouvement en protected. Comme ça, dans les classes concrètes qui en héritent, je peux profiter de la génération automatique des opérations de copie et de mouvement, quand les variables membres le permettent.

+1 pour le reste.

PS : std::allocator::destroy est déprécié en C++17. std::allocator_traits::destroy appelle directement le destructeur si l'allocateur n'a pas de méthode destroy.

Je pense au contraire qu'il est rarement pertinent de permettre copie et affectation au niveau des interfaces, même protégé. Car:
1- c'est ouvrir la porte au slicing entre les enfants non abstraits
2- certaines opérations sont incompatibles avec la copie (hash, comparaison) si on veut respecter symétrie, réflexivité, transitivité et LSP.
3- et que du coup, héritage et copie sont rarement compatibles et mon défaut est l'interdiction. Faire autrement est rangé dans la catégorie refactoring lourd chez moi.

Oui, j'avais vu la moitié des infos pour destroy(), mais sans prendre le temps de chercher où c'était passé.

Citation:

---

Envoyé par Luc Hermitte

2- certaines opérations sont incompatibles avec la copie (hash, comparaison) si on veut respecter symétrie, réflexivité, transitivité et LSP.

---

Quel est le rapport avec la copie ? :koi:
Aurais-tu un petit bout de code pour illustrer le problème avec un constructeur de copie et une affectation de copie en protected dans l'interface ?

Je pense que Luc veut dire :mrgreen:, ne pas surcharger les classes mères inutilement et/ ou de façon trop transparente, parce que si les classes filles ne prennent pas le temps de [réfléchir à]/ redéfinir ces méthodes (qui peuvent leur être inutile) cela peut entraîner des effets de bord, comme, par exemple:

• le "slicing" - lors de la copie seule la partie de la classe mère est prise en compte
• des méthodes qui font n'importe quoi - lors de la copie, la comparaison de 2 empreintes numériques "hashs"

J'avais écrit trop vite. L'incompatibilité, c'est avec l'héritage. Au temps pour moi.
Le rapport avec la copie est que la comparabilité est l'autre facette de la sémantique de valeur, même si j'ai l'impression que l'on observe un glissement sémantique, où on va maintenant parler d'objet régulier quand copie et comparabilité sont supportés (même s'il n'y a plus de notion d'ordre que l'on avait dans les définitions précédentes de "régulier").

En résumé de 150 précédentes discussions
- copie et héritage (public) ne sont pas techniquement compatible à cause du slicing
- héritage (public) et comparabilités ne sont pas conceptuellement compatibles à cause de l'impossibilité d'avoir symétrie, réflexivité, transitivité et LSP en même temps sur les opérations de comparaison de type égalité
- copie et héritage sont rarement nécessaires en même temps (on est de nouveau sur le conceptuel)

Salut,

En ce qui concerne la notion d'interface, je crois qu'il y a plusieurs cas à prendre en compte:

Soit on considère de respecter la notion d'interface telle que décrite, par exemple, en java : une classe qui n'expose que des fonctions membre virtuelles pures et qui ne contient aucune donnée propres (à charge pour les classes qui l'implémentent d'apporter les données nécessaire à la définition des fonctions membre).

Il semble clair que la copie (et l'affectation) n'a de toute manière aucun intérêt avec cette notion, vu que la copie n'agit que sur les données, et que le fait de l'autoriser n'apportera donc absolument rien.

Par contre, le fait de l'interdire présente pas mal d'avantage, car elle va empêcher le compilateur de mettre en place les processus de copie (et d'affectation) au niveau des classes dérivées. Cela peut servir de "garde fou" au développeur qui (devrait) se rendre compte que "quelque chose cloche" si sa classe concrète est sensée avoir sémantique de valeur; et cette garantie sera toujours "bonne à prendre" ;)

Soit on considère la notion d'interface d'une manière "plus souple" (et autorisée par le langage) comme... une classe à part entière, permettant d'exposer des comportements clairement définis (grâce aux données membres qui les composent), mais dont l'instanciation doit être effectuée au travers d'une classe dérivée. Cela pourrait prendre une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

class IPositionnable{ public: Position const & position() const; protected: IPositionnable(Position const &); ~IPositionnable(); void changePosition(Position const & ); private: Position pos_; }; /* voire même */ class IMovable{ public: void move(/* paramètres nécessaires*/) protected: IMovable(Position const &); ~IMovable(); private: };

---

Finalement, on retombe dans le premier cas que j'ai cité : l'interdiction de la copie apporte certaines garanties qui devraient permettre au développeur de se rendre compte qu'"il fait n'importe quoi" en décidant de faire hériter sa classe ayant sémantique de valeur de notre interface.

Enfin, il y a la possibilité de créer des interface template.

Nous sommes toujours dans le cadre d'une classe qui n'a pas vocation à être instanciée sans passer par une classe dérivée, mais dont l'objectif principal est de permettre à plusieurs classes d'exposer des comportements similaires, sans forcément être liées par une relation de substituabilité, car MonInterface<Truc> et MonInterface<Machin> n'auront une classe de base commune que si Truc et Machin ont elles-même une base commune.

Il n'y a que dans ce dernier cas que les choses sont -- à mon sens -- un peu moins claires, car tout dépend de l'usage auquel nous destinons notre interface

Notez d'ailleurs qu'il faudrait "pour bien faire" créer des politiques distinctes de manière à prendre les différents cas en compte ;) :

Soit cette interface est destinée à permettre à une hiérarchie de classe d'exposer certains comportements. Dans ce cas, nous nous retrouvons dans une situation totalement analogue au deux premiers cas que j'ai cité, et l'interdiction de la copie fait tout à fait sens.

Soit cette interface est destinée à permettre à plusieurs classes qui n'ont aucun point commun (en termes de substituabilité, s'entend) entre elles, si ce n'est qu'elles exposent des comportement identiques (mais potentiellement définis de manière différente). Dans ce cas très particulier, il se peut que notre interface soit pressentie pour servir de base à une relation d'héritage avec... une classe ayant sémantique de valeur.

Bien sur, nous sommes dans une situation très particulière, et donc particulièrement rare, d'héritage dans laquelle le LSP n'a absolument rien à voir dans l'histoire. Mais, du coup, il peut tout à fait faire sens de laisser la possibilité de créer une copie et / ou d'effectuer une affectation à partir de notre interface, ne serait-ce que pour garantir la sémantique de valeur aux classes qui l'implémenteront.

Au final, je suis très clairement de l'avis de Luc Hermite: de manière générale, et dans la plupart des cas, il est très certainement bien plus intéressant d'interdire la copie (et l'affecttation) des interfaces, même si les classes qui les implémentent devraient déjà avoir pris soin de le faire de leur coté ;)

Citation:

---

Envoyé par DJ reda

je suis nouveau ici et j'ai besoin d'aide les gas

des question pour test C++
Q1: Je suis un autre nom que l'on peut donner à une donnée membre, je suis ......
Q2: Je suis le principe selon lequel un objet est responsable de ses données et doit en contrôler l'accès, je suis .....
Q3: Je suis une forme d'héritage qui permet à une instance d'une classe enfant de faire appel à une méthode du parent, je suis .......
Q4: Je suis une forme d'héritage qui permet à un enfant d'avoir plusieur parents, je suis ......
Q5: Je suis le mécanisme qui permet, à travers une méthode disponible dans la classe ancêtre, de faire appel à une méthode spécifique d'une classe enfant, je suis .....
Q6: Je suis une classe qu'on ne peut instancier bien que mon constructeur soit public, je suis une classe......................

Merci pour votre aide

---

Ce sont pas des questions pour rentrer à l'UDES à tout hasard ? ^^