Problème d'include et d'héritage C++

Version imprimable

08/01/2022, 12h29
Mamena

Problème d'include et d'héritage C++
Bonjour,
Je viens de débuter le c++ et j'ai un projet à rendre avec comme consigne : faire un code sur le réchauffement climatique qui utilise le polymorphisme et l'héritage. J'ai donc créer 4 classes :
- Date qui a comme attribut : int jour, int mois, int annee
- Ville qui a comme attribut : string nom_v, float temperature, Date date
- Pays qui a comme attribut : string nom_p, Ville* tab_v, int nbVille, int maxVille
- Monde qui a comme attribut : Pays* tab_p, int nbPays, int maxPays
Du coup pour que tout marche j'ai include :
- Date dans Ville
- Ville dans Pays
- Pays dans Monde
- Monde dans main
Or je me suis rendu compte qu'il n'y a pas d'héritage là dedans. J'ai donc voulu rajouter :
- Date qui hérite de Ville
- Ville qui hérite de Pays
- Pays qui hérite de Monde
Et pour faire ces héritages je dois inclure :
- Ville dans Date
- Pays dans Ville
- Monde dans Pays
Et c'est là que j'ai un problème d'include. J'ai donc essayé de rajouter
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #ifndef MONDE #define MONDE #include<string> #include "Pays.h" #include "Ville.h" #include "Date.h" using namespace std; class Monde{ ... } #endif
pour toutes mes classes mais j'ai quand même des erreurs du type :
Code:

1 2 ./Monde.h:12:3: error: unknown type name 'Pays' Pays *tabl;
Comment puis-je régler ce problème ?
08/01/2022, 13h48
koala01
Salut,

Bon, avant toute chose: tu vas surtout me faire le plaisir de virer l'attribut Ville * tab_v; et de le remplacer par un std::vector<Ville> tab_v; dans ta classe Pays

De même, tu vas également me faire le plaisir de virer l'attribut Pays * tab_p; de ta classe monde, et le remplacer par un std::vector<Pays> tab_p; dans la classe Monde.

Car nous sommes bel et bien dans une section dans laquelle nous parlons de C++!!! Or, il n'est plus question de gérer soi-même la mémoire pour les tableaux (ou pour les chaines de caractères) en C++ depuis ... 1998, si pas même plus tôt encore.

Il serait donc temps de se mettre un tout petit peu à jour, ne crois tu pas :question:

Mais comme tu ne sais peut-être pas ce qu'est la classe std::vector, ( ==>voici un lien vers sa documentation "officielle"<== ), disons qu'il s'agit d'une classe qui représente la notion de tableaux dont la taille peut varier en cours d'utilisation, et dont l'intérêt majeur est:
1. d'être en mesure de contenir "n'importe quoi", pour autant que ce soit toujours le même type de n'importe quoi (donc, toujours des pommes, ou toujours des poires, mais on peut pas les mélanger ;) )
2. de savoir en permanence exactement le nombre d'éléments qu'elle contient
3. de s'occuper elle-même de gérer la quantité de mémoire qui sera nécessaire pour pouvoir contenir l'ensemble des éléments qu'elle contient
Citation:

Or je me suis rendu compte qu'il n'y a pas d'héritage là dedans. J'ai donc voulu rajouter :
- Date qui hérite de Ville
- Ville qui hérite de Pays
- Pays qui hérite de Monde

Mais veux tu bien oublier ces infamies, s'il te plait !!!

As tu seulement compris ce qu'est l'héritage :question:

As tu seulement conscience qu'il s'agit de la relation la plus forte qui puisse exister entre deux classe :question:

Cela signifie que, parmi toutes les relations que l'on peut envisager de créer entre deux classes, l'héritage est par excellence celle pour laquelle on a le moins le droit à l'erreur, et qui ne peut donc surtout pas être décidée à la légère.

Pour être précis, l'héritage est une relation destinée à permettre la substituabilité selon les termes du principe de substituabilité de Liskov, c'est à dire que l'on doit pouvoir transmettre n'importe quelle instance de la classe dérivée (par exemple: une date, selon ce que tu t'apprête à faire) à n'importe quelle fonction s'attendant à recevoir une instance de la classe de base (c'est à dire une ville, et, par transition un pays ou même un monde, toujours selon ce que tu t'apprête à faire), et que le comportement de la fonction doit rester cohérent.

Autrement dit, bien que je n'aime pas trop le terme, l'héritage est une relation xxx EST-UN yyy.

Si bien que ce que tu t'apprête à faire, en gros, c'est à dire au compilateur qu'une date EST-UNE ville, qu'une vile EST-UN pays et qu'un pays EST-UN monde (et, par voie de transition, qu'une date est donc, tout à la fois, une ville, un pays et un monde)

Si tu avais la classe maison et la classe bâtiment, cela pourrait marcher, car on peut effectivement considérer qu'une maison EST-UNE (sorte particulière) de bâtiment, de même si tu avais les classes voiture, camion et moto, tu pourrais les faire hériter de la classe véhicule, car aussi bien les motos que les voitures ou les camions sont effectivement une sorte particulière de véhicules.

Mais ce que tu veux faire ici n'a purement et simplement aucun sens ;)

De plus, le principe de substitution de Liskov nous fait comprendre qu'on ne peut pas vraiment se limiter à cette notion de xxx EST-UN yyy, parce que toutes les propriétés démontrables et valides pour la classe de base doivent forcément être démontrables et valides pour la classe dérivée.

Ainsi, nous avons tous appris qu'un carré est un rectangle ayant quatre coté égaux. Nous pourrions donc croire qu'il est "logique" de pouvoir faire hériter une classe carrée de la classe rectangle, n'est ce pas :question:

Et pourtant, non, on ne peut pas le faire, car un rectangle va présenter deux propriétés valides importantes: la possibilité d'en obtenir la longueur et celle d'en obtenir la largeur. Or, ces deux propriétés n'ont absolument aucun sens.

De plus, les règles de la programmation par contrat applicables pour l'héritage nous disent que
Citation:
Les préconditions (les conditions qui doivent être remplies au plus tard au moment où une fonction est appelée pour que la donnée soit considérée comme valide) ne peuvent pas être renforcées dans une sous-classe.
Les postconditions (les conditions qui doivent être remplies au plus tard à la fin de l'exécution d'une fonction pour que la donnée soit considérée comme valide) ne peuvent pas être affaiblies dans une sous-classe
Or, la notion de carré a une précondition beaucoup plus stricte que la notion de rectangle: les quatre cotés doivent être égaux pour le carré, alors que les cotés ne doivent être égaux que deux à deux pour le rectangle.

Et rien que cela nous empêche de faire hériter la classe carré de la classe rectangle.

Or, il n'y a déjà aucun point commun entre date, ville, pays et monde, et il n'y a donc pas le "plus petit bout" par lequel il serait envisageable de "raccrocher tout cela" dans une hiérarchie de classes. Comprends tu pourquoi c'est totalement impossible et pourquoi je t'agresse en te demandant d'abandonner cette infamie :question:

Et sinon, pour quand même t'expliquer le pourquoi de l'erreur que le compilateur te renvoie:

Je parie que tu as une instruction #include "monde.h" dans pays.h, afin de pouvoir déclarer l'héritage :question:

Mais, du coup, cela veut dire que tu as pays.h qui inclut monde.h, et monde.h qui inclut pays.h, qui ... inclut monde.h, qui inclut pays.h, qui inclut monde.h (et je pourrais continuer 110 ans comme cela sans en voir le bout), avec pays qui a besoin de connaitre monde pour pouvoir en hériter, et avec monde qui a besoin de pays pour pouvoir en contenir un tableau

Connais tu Ouroboros? C'est un serpent mythique qui se bouffe lui-même la queue. Ben tu fais exactement comme lui, pour l'instant. Et le compilateur -- qui sera toujours plus têtu que toi -- ben il est pas d'accord ;)
08/01/2022, 15h56
Mamena
D'abord merci pour ta réponse complète et compréhensible.

Citation:

Bon, avant toute chose: tu vas surtout me faire le plaisir de virer l'attribut Ville * tab_v; et de le remplacer par un std::vector<Ville> tab_v; dans ta classe Pays
De même, tu vas également me faire le plaisir de virer l'attribut Pays * tab_p; de ta classe monde, et le remplacer par un std::vector<Pays> tab_p; dans la classe Monde.
Il serait donc temps de se mettre un tout petit peu à jour, ne crois tu pas ?

Durant mes cours a l'université on m'a appris a faire les tableaux avec une étoile. J'ai juste suivi les cours de mon enseignant.

Citation:

As tu seulement compris ce qu'est l'héritage ?
As tu seulement conscience qu'il s'agit de la relation la plus forte qui puisse exister entre deux classe ?

Je pensais avoir compris mais j'avoue que ce n'est plus du tout clair dans ma tête.

Somme nous d'accord que dans le code de base tel que :
- Date qui a comme attribut : int jour, int mois, int annee
- Ville qui a comme attribut : string nom_v, float temperature, Date date
- Pays qui a comme attribut : string nom_p, std::vector<Ville> tab_v; int nbVille, int maxVille
- Monde qui a comme attribut : std::vector<Pays> tab_p, int nbPays, int maxPays
il n'y a pas d'héritage ? Quel est donc la relation entre ces classes ?

Citation:

Autrement dit, bien que je n'aime pas trop le terme, l'héritage est une relation xxx EST-UN yyy.

Peut-on alors dire Pays EST-UN ensemble de Villes ? (et de même pour Monde)

Citation:

Or,il n'y a déjà aucun point commun entre date, ville, pays et monde, et il n'y a donc pas le "plus petit bout" par lequel il serait envisageable de "raccrocher tout cela" dans une hiérarchie de classes. Comprends tu pourquoi c'est totalement impossible et pourquoi je t'agresse en te demandant d'abandonner cette infamie ?

Je comprend oui mais n'y a t-il pas un moyen pour faire apparaitre de l'héritage dans ces classes ?

Citation:

Je parie que tu as une instruction #include "monde.h" dans pays.h, afin de pouvoir déclarer l'héritage ?

Exactement et je comprend très bien le fait que le serpent se mord la queue mais je pensais qu'il existait des solutions pour contourner ce problème.
08/01/2022, 18h30
koala01
Citation:

Envoyé par Mamena

D'abord merci pour ta réponse complète et compréhensible.

Avec plaisir ;)

Citation:

Envoyé par Mamena

Durant mes cours a l'université on m'a appris a faire les tableaux avec une étoile. J'ai juste suivi les cours de mon enseignant.

Ouchh... Ca risque, du coup, d'être encore pire que ce que je pensais :vomi:

Rassures-moi vite sur deux points, s'il te plait:
1- Ton cursus "de base", il n'a rien à voir avec la formation d'ingénieur en informatique, et la programmation n'est qu'une matière vue parce qu'elle sera utile pour ton travail par la suite, n'est-ce pas :question:
2- Tu sais quand même ce que représente l'étoile dans ce contexte, et tu as juste oublié que l'on parle de pointeur ... c'est ca :question:

Mais ton prof, il est à lapider et à lyncher sur la place publique!!!
Je m'étonnais encore pas plus tard que ce matin d'avoir lu une réponse (sur un site qui n'est pas dédié à l'informatique) qui tournait autour de

Citation:

Ce langage [le C++] est l'héritier d'un temps révolu que les débutants peuvent éviter en se tournant vers python par exemple.

Mais si les cours d'université qui doivent vous apprendre les rudiments du C++ sont à ce point mauvais, cela ne m'étonne absolument plus !

Allez, bien qu'il ne s'agisse pas d'un cours, voici la manière dont il faudrait aborder l'apprentissage du C++ depuis au moins vingt ans (meme si la video ne date que d'il y en a cinq (désolé, c'est en anglais):
https://youtu.be/YnWhqhNdYyk

Citation:

Envoyé par Mamena

Je pensais avoir compris mais j'avoue que ce n'est plus du tout clair dans ma tête.

Est ce que les explications qui ont suivi t'ont permis de fixer un peu les choses:question: As tu compris l'ensemble de ce que je disais :quetion: ou peut-être faut il que je revienne sur un point ou l'autre :question:
Citation:
Envoyé par Mamena

Somme nous d'accord que dans le code de base tel que :

Date qui a comme attribut : int jour, int mois, int annee
Ville qui a comme attribut : string nom_v, float temperature, Date date
Pays qui a comme attribut : string nom_p, std::vector<Ville> tab_v; int nbVille, int maxVille
Monde qui a comme attribut : std::vector<Pays> tab_p, int nbPays, int maxPays

il n'y a pas d'héritage ?
C'est exactement cela ;)

Citation:

Envoyé par Mamena

Quel est donc la relation entre ces classes ?

Ben, n'importe quelle autre relation qui ne soit pas de l'ordre de l'héritage (généralisation/ spécialisation) parmi celles qui restent (à savoir les associations) : composition ou agrégation.

Agrégation si l'élément "le plus petit" ne sait pas exister sans être maintenu en mémoire dans l'élément le plus grand (la date dans la ville, la ville dans le pays, le pays dans le monde), c'est le genre de relation que je t'ai "naturellement" proposé ici ;)

Composition si l'élément le plus petit peut exister "indépendamment" de l'existence de toute relation avec l'élément le plus grand (si la ville existe "par elle-même" et que le pays peut malgré tout y accéder)

Citation:

Envoyé par Mamena

Peut-on alors dire Pays EST-UN ensemble de Villes ? (et de même pour Monde)

Oui... Mais non en fait.

On aborde ici la raison pour laquelle je n'aime pas présenter l'héritage selon ce terme pourtant "consacré" de "relation EST-UN".

Oui, parce que c'est bel et bien la manière dont les gens pourraient s'exprimer en dehors de toute notion informatique:

Citation:

un pays est [composé d'] un ensemble de villes

Citation:

un carré EST-UN[état particulier du ] rectangle

qui vont sembler si proches (à cause des termes sous entendus) de la manière dont on exprimerait des relations correcte d'exprimer un héritage

Citation:

une voiture EST-UN véhicule

Citation:

une maison EST-UN bâtiment

C'est la raison pour laquelle je préférerais de loin qu'on désigne l'héritage comme une relation "EST SUBSTITUABLE A UN" en gardant le LSP (le principe de substitution de Liskov) en tête.

Pour le coup, tu me fais me rendre compte qu'il va y avoir un problème même avec cette manière d'exprimer les choses, car on pourrait -- effectivement -- se dire qu'un pays EST SUBSTITUABLE A UN ENSEMBLE DE villes, dans le sens où, si je devais avoir une fonction s'attendant à recevoir "un ensemble de villes" comme paramètre, ben, dans l'absolu, pourquoi ne pourrais-je pas lui transmettre un pays, n'est ce pas :question:

Et pourtant, ben, en fait, non, parce que les termes "ensemble de" se raccrochent directement à la notion de "collection d'éléments" (tableaux, piles, files, listes, arbres binaires de recherches, ...)

Or ces "collections d'éléments" ne sont pas des classes dont on peut hériter. Et cela pour plusieurs raisons. Je ne vais pas les détailler ici (ou du moins tout de suite), mais dis toi que les seules relations possibles entre n'importe quelle classe et une collection d'objet sont de l'ordre de l'association (agrégation ou composition), quitte à ce que la classe qui "reçoit" la collection ne décide d'exposer certaines fonctions fournie par celle-ci dans le domaine publique afin de permettre la "gestion" des éléments que la collection contient.

Citation:

Je comprend oui mais n'y a t-il pas un moyen pour faire apparaitre de l'héritage dans ces classes ?

Tel que les choses sont là, aucun.

On pourrait -- bien sur -- complexifier le projet pour arriver à faire apparaitre quelques relations d'héritages, cependant, ce serait complexifier inutilement le projet, et donc, le rendre beaucoup plus susceptible de présenter des bugs. Autrement dit cela ferait beaucoup plus de tords que de bien :calim2:

La règle d'or en programmation est toujours le rasoir d'Ockham: ne pas rendre les choses plus complexes que ce qui n'est absolument nécessaire ;)

Si tu veux absolument jouer avec l'héritage et le polymorphisme, on peut sans doute t'aider à imaginer un projet pour lequel il serait nécessaire y compris sur le thême de la météo, si c'est le domaine qui t'intéresse le plus (il faudra peut être avoir quelques discussions pour comprendre un peu mieux le domaine, cependant, cela reste une possibilité ;) ).

Mais ca, c'est une autre histoire, un autre projet :P

Citation:

Exactement et je comprend très bien le fait que le serpent se mord la queue mais je pensais qu'il existait des solutions pour contourner ce problème.

Encore une fois: oui, mais en fait non...

Oui, il y a moyen d'éviter le problème du serpent qui se bouffe la queue. Cependant, ces solutions ne sont pas adaptées lorsqu'il est question d'héritage, ou plutôt au fait qu'une classe de base doive connaitre la classe qui en serait dérivée afin de pouvoir intégrer une relation d'association.

Car c'est bel et bien ce que vous essayez de faire lorsque vous voulez faire hériter Ville de Pays (Pays est alors la "classe de base" et Ville la "classe dérivée') tout en faisant en sorte que la classe Pays contienne "un ensemble de villes".

Quelque part, le simple fait qu'aucune des relations d'héritage que tu as voulu décrire n'ait de sens te sauve la mise ici, car, si tu retire l'héritage, tu retire le problème, et "pas de problème" signifie "pas de solution à trouver" :D
09/01/2022, 12h01
Mamena

Citation:

1- Ton cursus "de base", il n'a rien à voir avec la formation d'ingénieur en informatique, et la programmation n'est qu'une matière vue parce qu'elle sera utile pour ton travail par la suite, n'est-ce pas ?
2- Tu sais quand même ce que représente l'étoile dans ce contexte, et tu as juste oublié que l'on parle de pointeur ... c'est ça ?

1- Non je suis en master 2 de mathématiques appliquées et on a eu 6h de cours et 10h de TP en C++, c'est vraiment une introduction.
2- Oui oui je sais que l'étoile représente un pointeur.

Citation:

Ce langage [le C++] est l'héritier d'un temps révolu que les débutants peuvent éviter en se tournant vers python par exemple.

Justement en math appliquées on utilise que le Python sans avoir abordé les langages bas niveau avant donc passer d'un langage qui nous fait le café a un langage bas niveau c'est très difficile à comprendre.

Citation:

Est ce que les explications qui ont suivi t'ont permis de fixer un peu les choses ? As tu compris l'ensemble de ce que je disais ? ou peut-être faut il que je revienne sur un point ou l'autre ?

Oui j'ai bien compris mais j'ai du mal a intégrer le fait qu'on puisse pas faire de l'héritage quand on veut. Pour moi on pouvait utiliser l'héritage dès lors qu'on avait besoin des attributs de la classe A dans la classe B. Mais j'ai bien compris que c'est faux !

J'ai quand même trouvé une solution pour faire apparaitre l'héritage dans mon code. Vous allez me dire que c'est une infamie c'est sûr :roll: Mais mon code fonctionne et vu que ma prof ne doit pas être une pro en C++, j'espère qu'elle n'y verra que du feu ! J'ai fait hérité Pays de Ville et Ville de Date. Je ne sais pas pourquoi ça marche mais ça marche ! Désolé pour cette horreur mais sur un malentendu ça peut passer :aie:

Citation:

Envoyé par Mamena

J'ai fait hérité Pays de Ville et Ville de Date.

:ptdr: :ptdr: Ce TP de l'enfer. Sans parler des tableaux C qui t'oblige à faire des allocations/ déallocations et de maintenir la taille/ la capacité. Et également qu'1 pays n'a pas de nom et la date d'1 ville c'est quoi :koi:

Si tu veux faire de l'héritage, il y a 1 truc qui saute directement aux yeux (après est-ce cela ou pas :mrgreen:)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 class One_Element { protected: std::string name; }; class One_City : public One_Element { // date, WTF // maybe size_t index, index of list_cities }; class One_Country : public One_Element { private: std::vector<One_City> list_cities; // maybe size_t index, index of list_countries }; class One_World : public One_Element { private: std::vector<One_Country> list_countries; };
Après, il faut savoir si tu veux des tableaux avec des éléments ou des pointeurs. Les redimensionnements, les copies, ... vont être [assez/ fortement] si les éléments sont assez gros et/ ou leur nombre est grand.

09/01/2022, 13h27
Mamena

Ça peut être une bonne idée. Pour moi une Ville c'est un prélèvement de température à un certain moment dans un certain lieu, c'est pour ça qu'il y a un string nom_v, Date date et int temp.
Mais je peux peut être créer une classe Prelevement qui as comme attribut une date et une température et la classe Ville ça sera juste le nom de la ville et elle héritera de Prelevement. Ça vous semble correct ?
09/01/2022, 13h44
foetus
Citation:

Envoyé par Mamena

Ça vous semble correct ?

C'est vraiment n'importe quoi :weird: la ville peut exister sans le prélèvement, mais le prélèvement lui non
Code:

1 2 3 4 5 6 class Temperature { private: Date date; int value; One_City& city; // or One_City* city; };

Citation:
Envoyé par foetus
Si tu veux faire de l'héritage, il y a 1 truc qui saute directement aux yeux (après est-ce cela ou pas :mrgreen:)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 class One_Element { protected: std::string name; }; class One_City : public One_Element { // date, WTF // maybe size_t index, index of list_cities }; class One_Country : public One_Element { private: std::vector<One_City> list_cities; // maybe size_t index, index of list_countries }; class One_World : public One_Element { private: std::vector<One_Country> list_countries; };
Après, il faut savoir si tu veux des tableaux avec des éléments ou des pointeurs. Les redimensionnements, les copies, ... vont être [assez/ fortement] si les éléments sont assez gros et/ ou leur nombre est grand.
Et encore!

Le principal objectif de l'héritage publique est de permettre d'utiliser indifféremment différents types de données (des voitures, des motos et des camions, par exemple) sous une forme plus "restreinte" (la notion de véhicule, selon mon exemple), mais qui soit commune à l'ensemble des données que l'on manipule.

La question est donc: y a-t-il le moindre intérêt, si on fait hériter One_city, One_Country et One_world de One_element d'être en mesure de créer une collection d'objets -- car c'est l'un des moyen les plus faciles de regrouper les données qui doivent être manipulées de la même manière) qui contiendrait une ville (Paris), un pays (la Belgique) et "le monde" :question:

Que pourrais-je vouloir faire sur ou à partir de ces trois données (Paris, la Belgique et "le monde") qui soit suffisamment commun aux trois pour que je puisse décider "qu'il y a du sens" dans le fait de donner la possibilité de le faire à partir d'une donnée que je ne connaîtrais que comme étant "de type One_element" :question:

Même le fait d'afficher le nom ne fonctionne déjà plus dans cette optique, car, si cela fonctionne pour une ville, pour un pays et même à la limite pour un continent (bien que cette notion n'existe pas pour l'instant), le monde n'a -- pour l'instant, et sans doute encore pour longtemps -- pas (besoin) de nom, et qu'il n'en aura pas besoin avant que l'on ait colonisé mars.

Est-ce que le seul plaisir d'avoir une fonction void print(ostream &); qui serait éventuellement exposée par One_element justifie que l'on puisse envisager de regrouper ces trois types de données (ville, pays et monde) dans une collection commune, le tout en tenant compte que le monde va sans doute provoquer l'affichage de plusieurs pays -- dont, très vraisemblablement, celui que nous aurons mis dans la collection -- et que l'affichage d'un pays vas sans doute provoquer l'affichage de plusieurs villes dont, très vraisemblablement, celle que nous aurons mises dans la collection :question:

Certains pourraient être tentés de répondre "oui" à ces questions, pour des raisons qui leur paraîtront parfaitement valables (et qui le sont d'ailleurs sans doute), que je ne partage simplement pas.

Pour ma part, je préfères avoir mes villes d'un coté, mes pays d'un autre, et le monde encore ailleurs, sans essayer de gérer ces trois notions de manière commune ;)

Citation:

Envoyé par Mamena

Justement en math appliquées on utilise que le Python sans avoir abordé les langages bas niveau avant donc passer d'un langage qui nous fait le café a un langage bas niveau c'est très difficile à comprendre.

C'est sûr, mais il faut bien voir où sont les différences et les points communs.

En Python, si tu as la classe Pays et la classe Ville, tu feras sûrement quelque chose comme :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class Ville: def __init__(self, nom): self.nom = nom class Pays: def __init__(self): self.villes = list() def ajouter(self, ville): self.villes.append(ville)
Tu ne penseras sûrement pas à faire :
Code:

1 2 3 4 5 class Ville: # ... class Pays(Ville): # ...
Non ?

Les points communs entre tous les langages, ce sont les concepts (héritage, composition, etc.) ; les différences, ce sont les syntaxes pour y arriver (list() en Python ; std::vector en C++).

Si ça peut (ou pas) te rassurer, les profs de C et de C++ à la fac sont rarement bons. Ils sont souvent bloqués dans les années 90, notamment en C++ car le langage a beaucoup évolué depuis 2011. On a tendance à t'apprendre du C++ tel qu'il était à l'origine : du C avec quelques features syntaxiques pour faire des classes. On est très très loin de ça aujourd'hui. Ca explique aussi les réponses de gens ici, qui font du C++ moderne (parce que c'est leur métier, contrairement aux profs de fac, que je ne blâme qu'à moitié (*)), et sont donc choqués de voir ce qu'on te demande de faire :mrgreen:

(*) oui, je suis de bonne humeur ce matin