Discussion :

[ytahasa04]

Bonjour je débute en c++ et j'ai un problème avec les classes et les fichiers ".h",je cherche une ressources en français pour éclaircir tous ça ou quelqu'un peut me faire comprendre tout ça avec un messages

[ternel]

Quel problème précisément?

Voici quelques questions à te poser:

• Qu'est le préprocesseur?
• Que signifie #include?
• Qu'elle est la différence entre déclaration et définition?
• Qu'implique l'ODR: la "One Definition Rule", c'est à dire, en français, la règle de la définition unique.
• Quand peut survenir le message d'erreur "Multiple definition of symbol ..."

Et en bonus, pourquoi ne pas lire l'anglais technique, alors que les langages sont définis dans ces langues?

[bacelar]

Et admettre qu'il n'y a pas UNE réponse à ta question.
Si tu réponds à toutes les questions de @ternel, tu sauras ce qu'il ne faut pas faire.
Pour savoir comment faire, c'est fonction du contexte : outils utilisés, manière d'utiliser ton code ( en code source direct, en librairie, etc...), et même comme cela il n'y aura pas UNE manière.

[koala01]

Salut,

Essayons de faire simple : le compilateur va lire le code exactement comme tu lirais un bon roman:

Quand tu lis la page 10 de ton roman, tu sais tout ce qui a pu se passer durant les neuf premières pages, tu connais tous les personnages qui se sont présenté durant ce temps, mais tu ne sais absolument rien de ce qui va se passer à la page 11 (et au suivantes), des personnages qui apparaîtront par la suite.

Mieux encore, si tu es à la troisième phrase de la dixième page, tu ne sais pas ce que va te dire la quatrième phrase de la même page.

Si tu remplace le terme "page" par le terme "unité de compilation" et le terme "phrase" par le terme "instruction, il n'y a qu'une seule grosse différence entre le compilateur et toi: Le compilateur n'accepte un identifiant (de donnée, de type de donnée, de fonction ou d'espace de noms ) que... s'il sait que cet identifiant existe, et qu'il est en mesure de "faire le lien" entre ce qu'est sensé représenter cet identifiant et ... l'usage qui en est fait.

Le problème du compilateur et alors qu'il ne connaît, à la base que:

• 96 (au dernier comptage, incluant ceux qui ne seront officialisés qu'en 2020) identifiants que l'on désigne sous le terme de mots clé.
• 5 opérateurs mathématiques (+,-,*,/ et %)
• 5 opérateurs logiques (&, &&, |, || et !)
• 5 opérateurs de comparaison (==, !=, <, <=, > et >=)
• 3 opérateurs "bits à bits" (<<, >> et ~)
• quelques paires de symboles auxquelles il donne une signification particulière ((), [], {})
• quelque symboles (parfois regroupés) auxquels il donne une signification particulière ( &, *, ->, . et ;)

ET C'EST TOUT!!!! (à moins que je n'ai oublié quelque chose, ce qui est toujours possible )

Notre problème à nous -- développeurs -- c'est que nous voulons pouvoir regrouper les différentes fonctionnalités "qui vont bien ensembles", mais d'une manière "minimaliste": Ce n'est pas parce que nous utilisons souvent des notions comme celles de "sortie standard", de "chaine de caractères" ou de "tableau" ensembles, que nous voulons forcément disposer de toutes les fonctionnalités en même temps :

Il arrive en effet régulièrement que nous voulions utiliser la notion de tableaux pour des données qui n'ont absolument rien à voir avec des chaines de caractères, et / ou que l'on ne voudra pas forcément afficher sur la sortie standard (et je pourrais suivre le même raisonnement avec toutes les combinaisons possibles )

Nous allons donc essayer de "compartimenter" (de "modulariser", pour reprendre le terme consacré) les différentes fonctionnalités lorsque nous ferons nos regroupements. Mais, cela pose premier problème technique, parce que toute fonctionnalité ne vaut que par l'usage qui en est fait:

Que je crées un type de donnée particulier ou que je fournisse une fonction destinée à obtenir un résultat bien précis, si le type de la donnée ou la fonction n'est pas utilisé(e), j'ai "perdu mon temps", j'ai travaillé pour rien

Cela devient un problème existentiel à cause du fonctionnement même du compilateur (il doit connaître tout ce que l'on utilise) et de l'outil (appelé "éditeur de liens") qui est utilisé pour regrouper les différents modules.

En effet, si le compilateur n'accepte d'utiliser que ce qu'il connaît, l'éditeur de liens, lui, voudra être en mesure de retrouver le code binaire exécutable (le code qui contient les instructions telles qu'elles seront comprise par le processeur) de toutes les fonctions que nous utiliserons.

Mais, s'il trouve du code binaire exécutable en double (ou en tripe) exemplaire pour une fonction particulière, il sera pas content non plus

Du coup, nous devons séparer notre travail en deux parties :

• les "fichiers d'en-tête" (ces fichiers qui prennent, entre autres, des extensions en *.h, *.hpp, *.hxx ou encore *.hh) qui permettront au compilateur de savoir que "quelque chose" existe et
• les fichier "d'implémentation" (ces fichiers qui prennent, entre autre, des extensions en *.cpp, *.cxx ou encore *.cc) qui contiendront le "corps" des fonctions pour lesquelle le compilateur devra générer le code binaire exécutable (destiné au processeur).

Les fichiers d'implémentations correspondent chacun à ce que j'ai appelé plus haut une "unité de compilation", et seront les seuls fichiers réellement pris en compte -- de manière strictement séparée (comprend : le compilateur oublie ce qu'il a pu faire lors du traitement de a.cpp lorsqu'il se met à traiter b.cpp) -- par le compilateur

Pour que le compilateur connaisse "tout ce qu'il doit connaître" -- et qui lui est fourni au travers des fichiers d'en-tête -- nous allons utiliser un troisième outil (qui sera utilisé en premier ) appelé le préprocesseur. Ce premier outil va reconnaître -- entre autres -- les directives #include <XXX.hpp> et se contenter de les remplacer -- de manière récursive -- par l'intégralité du contenu du fichier indiqué, si bien que , quand le compilateur "prendra le relais", il sera en mesure de connaître le contenu de l'intégralité du fichier inclus, et, au delà, le contenu de tous les fichiers qui ont été inclus dans un fichier d'en-tête.

Un "bon" fichier d'en-tête va donc contenir:

• la définition des types de données définis par l'utilisateur que tu décidera de créer
• la déclaration des fonctions qui seront utilisées pour manipuler ces types de données
• (éventuellement) les déclaration de toutes les données globales relatives à ces types de données (*)

Et, dans l'idéal, nous veillerons à ce que chaque fichier d'en-tête ne s'intéresse qu'à un seul "aspect du problème", qu'à un seul type de donnée particulier (et / ou à une seule optique de manipulation de ce type de donnée).

(*)NOTA : nous ne le répéterons jamais assez : les variables globales C'EST MAL!!!

Sur ce point particulier, il faut donc comprendre que, les données "constantes" (comme la donnée Pi qui vaudra toujours 3.1415926) ne poseront aucun problème, mais qu'il faut se méfier comme de la peste des variables (ces données dont il est possible de modifier la valeur "en cours de route"), si bien que nous éviterons -- sauf quelques exceptions bien particulière -- autant que possible d'y avoir recours.

[Daïmanu]

Bonjour.

Ce site dispose d'une bien fournie qui devrait t'apporter des réponses précieuses : https://cpp.developpez.com/faq/cpp/.
Elle fournit beaucoup d'informations mais en l’occurrence, les chapitres qui t’intéressent sont les classes en C++ et surtout l'organisation du code source.

[ytahasa04]

Merci à tous surtout pour koala01 pour ses explications,mon problème c'est que chaque cours sur internet n'est pas assez complet il y a des cours qui mettent des choses puis des autres mettent autres choses et ce qui complique les choses c'est le manque des cours en français je cherche un cours c++ avec des quiz toutes les choses qui aident a mieux comprendre le langage et l'utiliser.

cordialement,

[bacelar]

mon problème c'est que chaque cours sur internet n'est pas assez complet il y a des cours qui mettent des choses puis des autres mettent autres choses

Comme je l'ai déjà écrit, il n'y a pas une manière unique de faire ces choses.
Chaque cours est vraisemblablement cohérent avec lui-même.
Si vous glanez des informations "très spécifiques" d'un cours à un autre, vous n'obtiendrez rien de bien cohérent, surtout si vous ne lisez jamais les cours en entier.

Je vous conseille donc de prendre UNE bonne référence, qui est cohérente avec elle-même, qui explique les "règles" inamovibles ; et comment, avec ces règles, on utilise concrètement dans un contexte ou dans un autre.

Les règles inamovibles vous ont déjà été données par @koala01 et, indirectement par @ternel.

Sinon, il reste les bouquins en anglais.
https://www.amazon.com/Primer-5th-St.../dp/0321714113

Après, il se peut que vous bloquiez sur un problème précis, mais, là, faudrait un peu plus caractériser votre question.

[ytahasa04]

Merci à tous.