Bonjours je suis entrain de suivre un livre ou il me dit de faire un code pour dire "bonjour, maitre" et voici le code et il ne fonctionne pas aider moi s'il vous plait :
Bonjour, Merci de lire les règles du forum AVANT de créer un sujet. Merci d'indiquer un titre de sujet en rapport avec votre problématique.
Le message qui suit est une réponse automatique activée par un membre de l'équipe de modération. Les réponses automatiques leur permettent d'éviter d'avoir à répéter de nombreuses fois la même chose, ce qui leur fait gagner du temps et leur permet de s'occuper des sujets qui méritent plus d'attention. Nous sommes néanmoins ouverts et si vous avez une question ou une remarque, n'hésitez pas à contacter la personne en question par Message Privé. Pour plus d'informations, nous vous invitons à lire les règles générales du forum
Merci de colorer votre code à l'aide du bouton Code </>
Les forums d'Openclassrooms disposent d'une fonctionnalité permettant de colorer et mettre en forme les codes source afin de les rendre plus lisibles et faciles à manipuler par les intervenants. Pour cela, il faut utiliser le bouton </> de l'éditeur, choisir un des langages proposés et coller votre code dans la zone prévue. Si vous utilisez l'éditeur de messages en mode Markdown, il faut utiliser les balises <pre class="brush: php;">Votre code ici</pre>.
Merci de modifier votre message d'origine en fonction.
Mauvais titre
Le titre est un élément important qui ne doit pas être négligé. N'oubliez pas cette règle simple : le titre idéal résume la question que vous allez poser en une petite phrase. Il doit permettre aux visiteurs de se repérer facilement dans le forum visité et d'identifier le sujet à sa seule lecture.
Vous pouvez utiliser divers préfixes comme [Erreur], [MySQL], [Compatibilité], etc... Aussi, pensez à consulter les règles propres à chaque forum (visibles dans les topics épinglés en haut des sections).
De plus, choisir un bon titre permet de rendre plus faciles les recherches des autres membres.
Les titres de type "besoin d'aide" ou "problème" ne sont pas tolérés.
Merci de modifier votre titre. Pour cela, éditez le premier message de votre sujet.
(titre originel : Aider moi s'il vous plait)
Manque de précisions
Vous êtes ici sur un forum d'entraide communautaire et non pas sur un forum de demande de service, le but n'est donc pas de fournir une réponse toute faite ou de directement fournir la solution à quiconque viendrait sans la moindre trace. Afin d'obtenir de l'aide et une solution à votre problème, il est fortement recommandé de présenter clairement l'état actuel du problème en nous fournissant :
Un descriptif clair et précis du problème
La tentative actuelle de résolution que vous avez effectué
Le résultat attendu et le résultat actuel
Toutes pistes de recherches pouvant aider à la résolution
il va falloir trouver un livre plus à jour parce que depuis fort longtemps, dans les déclarations de fonction on indique le type retourné, et c'est int pour main
int main()
{
....
}
ou alors, faire des efforts pour recopier sans en oublier.
Bon, je vais y aller d'une hypothèse: tu exécutes ton code à partir de ton ide (code::block p.ex.).
Si c'est le cas, tu n'as pas le temps de voir la réponse (car ton code est ok) car la fenêtre de résultat s'ouvre et se referme immédiatement.
Dans ce cas, une rustine (mais ce n'est qu'une rustine): ajoute getchar(); après le print(). Tu devras appuyer sur touche pour femer la fenêtre résultat.
La bonne solution, c'est de paramétrer ton ide pour qu'il ne ferme pas la fenêtre de résultat à la fin du programme, mais qu'il attende que tu appuyes sur une touche.
- Edité par edgarjacobs 5 avril 2024 à 1:15:23
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Bonjour Pierrot. Si si, je suis ravi de ton idée, car je n'utilise pas d'ide. J'écris mes codes avec notepad++ et les compile en ligne de commande, avec make ou un .bat généraliste, style
Mais voilà, la plupart des tutoriels C (si pas tous) commencent par "installer votre environnement de travail", autrement dit "installer votre ide"
Je crois même que c'est valable pour tous les tutoriels du site du Zéro, et tous ceux qui s'en sont inspirés par la suite. J'ai même parfois l'impression que chaque auteur d'un tutoriel se sent obligé de faire découvrir un nouvel IDE (impression sûrement trompeuse, peut-être que c'est juste que certains IDE sont plus adaptés à certains langages).
Je suis partisan de séparer. Il faut des tutoriels pour apprendre à utiliser efficacement un IDE, on le voit bien ici où en gros la moitié des demandes d'aide concernent non pas le langage mais l'utilisation de l'IDE. Mais je trouve qu'apprendre à utiliser l'IDE doit se faire au moment opportun : quand le besoin existe. Un apprentissage est toujours plus efficace quand celui qui apprend a besoin de la notion : ça a alors un sens. Or il n'en a pas besoin pour programmer "hello world".
----------
joel76 a écrit:
Désolé mais ça fait quand même vieux hippie de gauche.
Pour le debug, tu fais comment ?
Vieux hippie de gauche, ça me convient bien : mes langages préférés sont le Fortran 77, le C et le Postscript. Donc je me sens visé (voire flatté ). Comme je n'écris pas de gros programmes, que je n'écris jamais 250 lignes d'un coup, que je découpe en petits sous-programmes et que je suis méthodique en cas de bug, je m'en sors toujours avec des affichages.
Il y a une discussion où j'explique comment faire dans un cas assez complexe, j'ai gardé un lien... voyons... Ah, je l'ai : https://openclassrooms.com/forum/sujet/operation-matricielle . Plus que l'outil, ce qui m'a semblé important ici était de comparer étape par étape ce que faisait le programme avec des calculs à la main (avec une calculatrice quand même). Avec un débogueur on mettra juste des points d'arrêt là où j'ai mis des printf, c'est pareil.
Moi, j'ai débuté avec le fortran sur bande perforée puis le C avec Vi et la compilation en ligne de commande, ça ne me rajeunit pas...
Mais bon, le pas à pas avec l'IDE c'est quand même bien pratique, il ne faut pas cracher sur les progrès.
J'ai longtemps fait du C de manière pro, mais j'ai découvert plus tard Prolog (je crois que tout développeur devrait sérieusement s'y intéresser, c'est vraiment une autre manière de réfléchir), et les langages fonctionnels.
Les fanas de C devraient faire un tour vers Rust, ça ressemble beaucoup au C, mais on n'a plus à se farcir les malloc/free et les fonctions d'accès aux listes sont déjà toutes écrites, et sont surement bien plus efficaces que ce que je pourrais faire !
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
@PierrotLeFou : Lorsque je faisais du Fortran au début des années 70, on avait un créneau de 60 minutes sur l'ordi situé à Lille (j'étais à la fac de Rouen), On tapait notre code sur des perforatrices dédiées, il y en avait une qui avait une aiguille défectueuse, l'opératrice le savait et rajoutait à la main le trou manquant !
J'étais très content d'arriver à faire des organigrammes pour calculer le déterminant d'une équation du second degré !!!
Sur mon premier ordi, on chargeait le dos sur disquette 5 pouces si je me souviens bien.
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Désolé mais ça fait quand même vieux hippie de gauche.
Pourquoi "de gauche" ? J'en ai connu de droite qui étaient très sympathiques
joel76 a écrit:
Pour le debug, tu fais comment ?
Pas besoin de debug, ce que j'ai codé fonctionne toujours du premier coup
______________________________________________
Blague à part, je code comme @robun le fait: je code (rarement) plus de 25/30 lignes sans faire de test. Et en travaillant de la sorte, il est assez aisé de corriger une erreur (avec des affichages si nécessaire). Mais bon, je suis maintenant hors du circuit professionnel.
Mais je préconise l'utilisation d'un debugger. Hélas, j'ai comme l'impression que durant leurs études, les élèves n'en entendent pas parler.
Dans les années '80, j'ai été épaté par le debugger inclus dans l'ide de Borland Turbo C 2.0 ! Et il y avait de quoi: études faites sur mainframe ibm 360 (ou 370, sais plus), engagé dans une sprl (Cobul sprl) pour travailler en Cbasic sur Olivetti M24 (au départ, juste deux lecteurs de floppy disk 360K et 256 Ko de mémoire), avant que le boss décide de tout migrer en C. Quelle découverte que cet ide ! (le C, je connaissais ~, j'avais fait un stage d'étude qui portait sur ce langage).
- Edité par edgarjacobs 7 avril 2024 à 19:59:05
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Débugger, c'est difficile à enseigner. Ce qui est facile, c'est d'enseigner comment poser des points d'arrêt, d'exécuter en pas à pas et regarder le contenu des variables.
Mais c'est beaucoup plus compliqué que ça : imaginer ce qu'est censé faire un bout de code (peut être écrit par quelqu'un d'autre), confronter avec la réalité, réduire le problème etc. Trouver ce qui a poussé à faire le bug... Y a de la méthodologie, et de l'expérience à acquérir.
C'est plus compliqué que programmer, en fait. C'est pour ça qu'il ne faut pas faire d'erreurs en programmant.
Écrire les tests des petits bouts avant, ou en même temps qu'on les code, c'est une démarche efficace. On n'est plus avec les cartes perforées, avec les moyens actuels, refaire tourner 50 tests à chaque recompilation pour voir si on n'a rien pété, c'est rentable.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Le Tout est souvent plus grand que la somme de ses parties.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !
Le Tout est souvent plus grand que la somme de ses parties.
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
Le Tout est souvent plus grand que la somme de ses parties.
Le crayon la gomme et le papier sont les meilleurs outils du programmeur !