Je viens de me lancer dans ce cours. J'ai téléchargé et installé CodeBlocks pour Windows. Tout se passait bien jusqu'à la partie "Initiez-vous à la programmation modulaire".
J'ai scrupuleusement suivi les instructions de la vidéo pour réaliser l'exercice relatif au calcul de l'aire d'un rectangle.
J'ai créé les fichiers aire.h et aire.c qui sont en tous points identiques à ceux de la vidéo :
fichier aire.h
fichier aire.c
J'ai enfin modifié le fichier main.c comme dans la vidéo.
C'est là que le problème apparait à la compilation
Je suis un nouvel utilisateur de CodeBlocks. Je ne vois pas où est le problème.
Petit indice qui parlera peut-être aux spécialistes.
Lorsque dans aire.c, j'ai tapé #include ", CodeBlocks m'a immédiatement proposé "aire.h" dans la liste déroulante.
Par contre, lorsque dans main.c, j'ai tapé #include ", CodeBlocks ne m'a pas proposé"aire.h" dans la liste déroulante. C'est peut-être normal mais je n'en sais rien.
Le compilateur est GNU GCC Compiler.
Y-at-il un problème de paramétrage du compilateur ?
Merci par avance pour votre aide.
- Edité par Jean-PaulReich 2 novembre 2023 à 17:40:26
Ton fichier aire.c n'est pas compilé et lié, on le voit dans ton "Build log".
Fais un click droit sur le fichier aire.c (Dans le panel de gauche) puis dans le menu tu fais "Properties" puis tu sélectionnes l'onglet "Build" puis tu coches "Compile file" et "Link file" puis Ok. Ensuite, ça devrait compiler.
L'édition des liens, ça sert à regrouper, pour fabriquer un exécutable
Les fichiers objets qui résultent de la compilation séparée des fichiers .c
Le "runtime" C et les bibliothèques utilisées
Les fichiers .h ne sont pas compilés séparément. Ils sont inclus dans les .c par les directives #include. C'est pas pareil.
Enfin, c'est logique quand on sait ça, quand le cours a pris la peine de l'expliquer avant, plutôt que de le laisser dans le rayon des trucs qu'on vous expliquera quand vous serez grands.
- Edité par michelbillaud 2 novembre 2023 à 22:36:07
Enfin, c'est logique quand on sait ça, quand le cours a pris la peine de l'expliquer avant, plutôt que de le laisser dans le rayon des trucs qu'on vous expliquera quand vous serez grands.
Ah, j'allais le dire ! Pendant mes études c'est pareil : on a eu des cours de programmation et je trouve qu'on est passé trop vite sur le sujet, au point que encore maintenant la compilation séparée est mon point faible (quand il y a des inclusions qui s'incluent... – mais c'est peut-être une mauvaise pratique et la preuve que je n'ai pas bien compris). J'en déduis que c'est un sujet pas si facile que ça et qui mérite de l'attention.
L'édition des liens, ça sert à regrouper, pour fabriquer un exécutable
Les fichiers objets qui résultent de la compilation séparée des fichiers .c
Le "runtime" C et les bibliothèques utilisées
Les fichiers .h ne sont pas compilés séparément. Ils sont inclus dans les .c par les directives #include. C'est pas pareil.
Enfin, c'est logique quand on sait ça, quand le cours a pris la peine de l'expliquer avant, plutôt que de le laisser dans le rayon des trucs qu'on vous expliquera quand vous serez grands.
"La commande #include demande d'insérer le contenu du fichier dans le .c. C'est donc une commande qui dit « Insère ici le fichier view.h», par exemple."
"Le contenu des fichiers .h est inclus en haut des .c par un programme appelé préprocesseur. Les .c sont transformés en fichiers .o binaires par le compilateur. Les .o sont assemblés en un exécutable (.exe) par le "linker", aussi appelé éditeur de liens."
Enfin, c'est logique quand on sait ça, quand le cours a pris la peine de l'expliquer avant, plutôt que de le laisser dans le rayon des trucs qu'on vous expliquera quand vous serez grands.
Ah, j'allais le dire ! Pendant mes études c'est pareil : on a eu des cours de programmation et je trouve qu'on est passé trop vite sur le sujet, au point que encore maintenant la compilation séparée est mon point faible (quand il y a des inclusions qui s'incluent... – mais c'est peut-être une mauvaise pratique et la preuve que je n'ai pas bien compris). J'en déduis que c'est un sujet pas si facile que ça et qui mérite de l'attention.
- Edité par robun il y a environ 7 heures
Dans l'enseignement des bases de la programmation (sur la base d'un "vrai" langage de programmation), on est plus ou moins obligés de botter en touche avec
"faites comme ça je vous expliquerai plus tard"
des simplifications outrageusement mensongères
Parce que le nombre de choses qu'il faudrait expliquer dans un simple "hello world" en C, c'est impressionnant (main est une fonction ? c'est quoi une fonction)
Dans la catégorie mensonges éhontés, en c++ il y a
cout << "hello";
où on dit que "cout est l'instruction pour faire afficher un truc".
---
pour la compilation séparée, le cours passe (autant que je me rappelle) complètement à coté de l'intérêt du truc, qui est de pouvoir faire plusieurs exécutables dont les codes sources ont des morceaux en commun.
Un exemple plus satisfaisant, ça serait
une bibliothèque de quelques fonctions qui font des trucs
un main qui fait passer des tests unitaires sur ces fonctions
un (autre) main qui utilise ces fonctions pour un truc utile
Résultat, le cours sépare des trucs, mais y a pas trop de raison de le faire en fait, et ça serait plus simple de s'en dispenser plutôt que de découper n'importe comment.
- Edité par michelbillaud 4 novembre 2023 à 16:03:25
pour la compilation séparée, le cours passe (autant que je me rappelle) complètement à coté de l'intérêt du truc, qui est de pouvoir faire plusieurs exécutables dont les codes sources ont des morceaux en commun. [...]
Entièrement d'accord ! Si on ne montre pas l'intérêt, ça ne passera pas.
Je trouve que la compilation séparée devrait être abordée plus loin, voire ne pas être abordée du tout si on considère que c'est un cours d'initiation. Il me semble plus prioritaire de savoir utiliser la bibliothèque standard (par exemple d'utiliser <string.h> ou <math.h>) que d'en créer une.
Et puis ça ajoute des difficultés à des gens qui se noient dans les difficultés propres au langage (je suis passé par là, qu'on ne me dise pas que le C est un langage facile...)
qu'on ne me dise pas que le C est un langage facile...
Bah si, C est un langage facile, du point de vue des instructions et des types de variables. Mais programmer (convenablement) en C, c'est une autre paire de manches :))
- Edité par edgarjacobs 5 novembre 2023 à 18:52:37
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Oui, tu as raison, ce sont deux choses différentes.
− Il n'y a pas beaucoup de concepts : pas de programmation objet, pas de surcharge d'opérateurs, etc. C'est de la programmation procédurale simple, et c'est pour ça que je programme en C (ou en Fortran si je dois manipuler des fichiers formatés).
− Mais utiliser ce langage pour faire ce qu'on voudrait, c'est ça qui est difficile au début. Lors de mes (mauvais) cours de fac, une fois sur deux je me prenais un « core dumped », souvent à cause de ce satané 'scanf'... (C'était d'autant plus frustrant que la programmation était mon point fort, mais en Pascal et Fortran). Le prof de C nous avait raconté que le C, c'était comme le Pascal à part la syntaxe légèrement différente. Ben voyons ! C'est quand je m'y suis remis, des années plus tard et à ma façon, que je suis enfin devenu à l'aise en C et qu'il m'a rendu service.
Les mécanismes qu'il propose sont assez basiques et peu nombreux, mais souvent piégeux. Déjà, on ne sait pas si les char sont signés, alors ça commence bien...
Et il y a eu la très mauvaise idée de représenter les chaînes par adresse du début + terminateur. Ça allait bien du temps où C était utilisé pour faire des bibliothèques ou réaliser des utilitaires de bas niveau, qui font fréquemment des appels système avec cette même convention, mais pour programmer des applications, c'est la galère.
- Edité par michelbillaud 6 novembre 2023 à 10:05:45
Si on veut des fonctionnalités un peu plus avancées, il faut se résoudre à utiliser des bibliothèques tierces (tient c'est un peu le sujet, il faut les lier). Et c'est moins facile de trouver ce qu'on souhaites si on compare à des langages qui ont un framework avec beaucoup de fonctionnalités qui les accompagne (java, C#...).
Y a eu une époque, dans les années 70, où la mode pour la conception des langages de programmation, c'était d'avoir un langage minimaliste, et de botter en touche vers des bibliothèques externes pour tout le reste (*). C est allé plus loin que Pascal, où les actions sur les fichiers (writeln etc) , l'allocation (new) étaient des instructions du langage, alors qu'en C c'est des appels de fonction.
(L'autre obsession, c'était d'écrire le compilateur dans le langage lui même !)
Le problème de botter en touche sur des bibliothèques tierce-partie (hors de la norme), c'est qu'il y en a plein qui font la même chose. Mais qui s'utilisent pas pareil. Et quand on bricole un gros logiciel, on se retrouve à recoller des bouts qui reposent sur l'une et des bouts sur une autre qui est censée rendre le même service. Il y a aussi le syndrome NIH, Not Invented Here, des gens qui tiennent mordicus à faire leur propre bibliothèque parce que si ils en prenaient une parmi des milliers qui font déjà le job, dieu sait ce qui pourrait arriver, peut être qu'il y aurait des bugs (eux, ils n'en font jamais), ou que ca serait pas optimisé (?) ou on pourrait avoir un procès.
Au moins, quand ça fait partie de l'écosystème standard, y a plus d'excuses de ce genre.
(*) une idée qui remonte à Algol, en fait.
PS: aussi que c'est "facile" et amusant de se bricoler un compilateur pour un nouveau mini-langage, et que les trucs utiles à faire en plus c'est la corvée.
- Edité par michelbillaud 6 novembre 2023 à 18:54:03
@MaliaDemoley Bonjour, merci de ne pas squatter le sujet résolu des autres, créer votre propre sujet dans le respect des règles du forum à savoir qu'un message commence par des règles de politesses (Un bonjour ou des salutations à la communauté et se termine par des remerciements par avances pour les futures réponses), la description de votre problème et le code que vous avez écrit inséré sur le forum à l'aide de l'outil d'intégration de code soit le bouton code </>.
Avant de poster un message, vérifiez la date du sujet dans lequel vous comptiez intervenir.
Si le dernier message sur le sujet date de plus de deux mois, mieux vaut ne pas répondre. En effet, le déterrage d'un sujet nuit au bon fonctionnement du forum, et l'informatique pouvant grandement changer en quelques mois il n'est donc que rarement pertinent de déterrer un vieux sujet.
Au lieu de déterrer un sujet il est préférable :
soit de contacter directement le membre voulu par messagerie privée en cliquant sur son pseudonyme pour accéder à sa page profil, puis sur le lien "Ecrire un message"
soit de créer un nouveau sujet décrivant votre propre contexte
ne pas répondre à un déterrage et le signaler à la modération
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent