Reprise du message précédent :
Attention : dans ce livre il y a des exercices, mais non corrigés.
A voir si tu aimes travailler sur des exercices ou non, ça dépend des gens.

C'est vital pour moi, j'ai du mal à assimiler la theorie sans exemples. On m'a offert un bouquin pour ça de toute façon. Pas de probleme. Je pense qu'un exo est un exo de toute façon.  
 
J'irai l'acheter des que possible !

Cela dit, en attendant, je vais devoir me debrouiller avec ce que je trouve ! lol
 
petite curiosité, concernant une interface graphique. On peut faire ça comment ? Des logiciels sont dispo ?

"Le langage C" par K&R est un tres bon livre pour debuter et comprendre les principaux mecanismes du C : pointeurs, tableaux, structures ... etc.
Mais je regrette tout de meme que les listes chainées ne soient pas abordées dans ce livre, ce qui est vraiment dommage.
Mais bon les listes chainees c est pas pour tout de suite, Stephaninho.
Par contre jette le livre que tu as actuellement ... des globales (qui de plus sont mal utilisées) dans un programme aussi basique, la declaration du main avant les autres fonctions du programme (mettre le main sous tes autres fonctions t evite d avoir a declarer le prototype de tes fonctions en debut de fichier. Pour un petit programme ca passe pour un plus gros on mettra les prototypes dans un fichier preprocesseur de type *.h mais jamais dans le fichier source *.c)
 

Mais ca reste le meilleur. Apres pour aller plus loin dans le C (systeme et bas niveau) c est google + RTFM

Dsl, mais les best practices en programmation encourage fortement de toujours écrire le prototype des fonctions.

2cent précise bien que les prototypes sont placés dans le .h  
En tout cas c'est comme ça que je comprends son post.
 
En tout cas, c'est ce que je fais aussi, sauf les fonctions static dont je me moque bien d'avoir le prototype, vu leur propagation

la seule chose qui compte c'est que c'est toujours plus sur si le prototype se trouve avant l'appel, faut pas oublier que malheureusement en C il n'est pas obligatoire (avant un appel), de même pour la déclaration mais la les compilos avertissent.

Quel en est l interet a part surcharger ton fichier source ??
De plus le preprocesseur est fait pour ca entre autre.
Sinon regarde le .h d une lib par exemple, et tu veras que tout les prototypes y sont mentionnés et par consequent ne figurent pas dans les sources mais la ca commence a etre hors sujet.
 

En C sous Unix/Linux tu fais intervenir des libs telles que la celebre X11 (ancestrale) ou bien GTK (plus recente).
Sous Windows il y a la MFC (l'explorateur et le demineur sont en MFC par exemple) mais c est du C++ et c est integré à visual studio.
 
s'il vous plait arretez d etre aussi rapide pour repondre j ai pas le temps de me justifier.
Merci Elmoricq et skelter d'avoir detailler tout ca.

GTK existe aussi pour Windows.

Je ne savais pas. Merci de l info.
Par contre sur Windows je pense que MFC doit etre plus adaptée.

 
d'accord, mais pour les fonctions static tu peux les prototyper au début du source et les définir à la fin, ca évite d'encombrer le début du source

 
Je suis d'accord, mais ça permet de créer des interfaces graphiques (presque) portables en C.
 

 
Je trouve qu'au contraire, prototyper une fonction qui n'est présente que dans le fichier source même, ça alourdit le code.
Mais bon, on en revient un peu aux goûts et aux couleurs, comme pour l'indentation, je trouve.

 
NON A MORT MFC §§§§§

Bon j avoue c est pas la meilleur lib graphique du monde : quand tu developpes avec la MFC tu as interet à t y connaitre un max
car quand ca plante et que tu dois debug, tu t amuses. Plus precisement ... developper en MFC avec du copier-coller tuto made in google = ca marchera jamais.
Mais ca reste la seule lib completement integrée à Windows.
 
Au fait le sujet c etait pas : Debuter en C  

 
Non, maintenant y'a .net
 
Pour un nouveau développement, c'est se tirer une balle dans le pied que de vouloir utiliser MFC: c'est chiant, c'est moche (ou bien faut passer 2 jours à faire 1 bouton), c'est obsolète, le rad est pourri, ca peut planter n'importe comment si tu passes pas systématiquement par le classwizard, y'a pas de xml dedans, .... j'arrête là.
 

Fallait pas invoquer le Malin

OK.

Mauvaise méthode. Il faut suivre une livre ou un tutoriel et cesser de bricoler. Le C c'est pas un langage de bidouilleurs. C'est pas non plus un langage de débutant en informatique... On n'apprend pas à conduire sur une formule 1...

Déjà, il faudrait regler ça...  
 
Ton code commenté et corrigé :

Si tu as des questions, beaucoup de réponses se trouvent sur mon site. Néanmois, pose des questions si tu ne comprends pas...

Une chose à la fois. Commence déjà par apprendre le langage C...
 
Après tu verras comment utiliser telle ou telle API ou bibliothèque... Il faut des notions qui dépassent celles, relativement simples, du langage.
 
Ne pas se précipiter, mais acquérir, assimiler et consolider...
 

Les listes chainées n'ont aucun rapport avec le langage C.
 

C'est fini de raconter n'importe quoi. La seul 'lib intégrée à Windows', c'est l'API Win 32. Point.
 

Au moins la MFC tu sais encore a peu pres ce que tu fais ... C++ tu as des pointeurs ... Dotnet y en a pas (enfin si y en a mais c est pas ce qu il y a de plus ergonomique a manier)
 

La je suis pas trop d accord. Je m explique : le C etant la base de pratiquement tous les langages avancés (je parle ici du C++ et C#), il me parait naturel de commencer par maitriser le C avant de se lancer dans l objet. Apres tu peux toujours te lancer dans les langages de scripting puissant comme PERL mais bon perso je ne considere pas ça comme un langage de programmation

Il faut cesser de parler de MFC sur un forum C. Persone ici ne sait ce qu'est une classe...

Commence donc par Pascal ou Ruby, Pyton etc.
 
Ne pas confondre "apprendre à programmer" et "apprendre un langage"...

La lib MFC est une implementation de l API Win32. L'API win32 n est pas la meilleur facon de commencer au developpement graphique
Stephaninho, qui je cite souhaitais connaitre une librairie pour developper du graphique, ne va surement pas se servir de l'API win32 elle meme pour commencer.

2Cent > arrête de troller stp

On parle bien de C sous Windows ... ce qui en soit n est pas la meilleur chose.

Alors renseigne toi sur GTK+...
 

Tu racontes vraiment n'importe quoi. Tu confonds .NET et C#...
 
Bref, va faire un tour, prend une douche, tu verras, ça ira mieux...

ouais, super, lolilol    
allez, un truc tout con : créé une classe dérivée de CDialog, dans son constructeur rajoutes y un CEdit, et met un texte par défaut à ce CEdit. l'opération vraiment de base quoi. compile, lance, attends que le vidage de la mémoire physique se termine, et dis moi si tu comprends ce qu'il est en train de t'arriver  
quant à l'histoire des pointeurs.... non rien

Que je rassures tout le monde, ce n'est pas maintenant que je ferai du graphique, j'aimerais d'abord maitriser raisonablement le C, après seulement j'irai massacrer le language pour faire l'interface graphique lol.
 
J'ai vu certain qui disaient qu'il était important de differencier l'apprentissage d'un language et de la programmation... Je suis parfaitement d'accord ! et je le sens.. J'ai fait du pascal mais quand on ne pratique pas ça s'oublie vite... donc j'ai evidement des restes mais c'est un parfois delicat.  
 
J'y retourne de ce pas... enfin, après manger  
 
merci encore

   
 
Y'a eu des blablatisations pour moins que ça

C'est vrai qu'il est bien le site d'Emmanuel !  
 
Juste une petite question au sujet de l'emploi de return, j'ai bien compris que c'était pour quitter la fonction mais il y a une petite remarque quand à la signification du 0 ou d'une autre valeur en lien avec les erreurs...  
 
précision quant au protype d'une fonction, d'après ce que j'ai compris, #include<stdio.h> nous permet d'eviter de d'ecrire un prototype de la fonction, ici puts() ? Dans quel cas il faut ecrire le prototype la fonction, lorsqu'aucun "fichier" de la bibliotheque ne le contient ? ce n'est pas à ce moment qu'on dit qu'il n'est pas reconnu par la norme ANSI ? du coup, comment le compilo reconnait cette fonction ?
 
je sais je sais.. plein de questions, des infos souvent issues de mon livre d'autre du site d'Emmanuel entre lesquelles j'aimerais faire un lien
 
merci

 
si aucun fichier d'en-tete public ne déclare la fonction c'est peut etre parce-qu'elle n'existe pas ? je comprend pas ta question
 

 
un fichier d'en-tete standard peut contenir des prototypes de fonctions standard et non standard, si tu compile en mode strict ANSI (-ansi sous gcc) les prototypes de fonctions non standard sont ignorés au moment de la précompilation

 
en C ANSI si une fonction n'est pas déclarée ca ne génère pas d'erreur, le compilateur génère une déclaration avec int comme type retour

return sert surtout à renvoyer une valeur à l'appelant. Evidemment return quitte la fonction mais il s'agirait plutôt d'une conséquence et non d'un but.
Maintenant, il peut t'arriver d'écrire des fonctions qui ont un rôle actif pour ton programme mais qui ne renvoient pas de valeur. Par exemple une fonction qui réinitialise une zone de travail. Tu lui passes en paramètre ta zone et la fonction s'occupe de la remettre à 0 (ce n'est là qu'un exemple). Donc tu as à ta disposition un outil de travail (le renvoi de valeur) qui est inutilisé par ta fonction. Alors tu te dis "je vais l'utiliser pour renvoyer à l'appelant une indication que la fonction s'est bien exécutée ou pas" avec la convention "0 = ok" et "pas 0 = problème". C'est pas lourd à implémenter et celui qui utilise ta fonction peut, s'il en a envie, utiliser et tester cette valeur de retour. Il peut aussi simplement l'ignorer. Mais au-moins tu as utilisé tous les outils à ta disposition pour renvoyer à l'appelant le maximum d'informations (surtout si tu commences à établir un code style "1 = erreur x, 2 = erreur y, 3 = erreur z, etc..." )

 
J'ai vu sur le site d'Emmanuel qu'il était parfois necessaire de donner le prototype de la fonction, seulement on ne le fait pas à chaque fois, dans quel cas ça s'avere necessaire ?  
 

 
Je suis désolé mais c'est justement ça que je n'arrive pas à comprendre...  

 
tu peux donner le lien en question sur le site d'Emmanuel ?

Bien sur,  
 
le voici : http://mapage.noos.fr/emdel/init_c.htm  
 
le programme qui dit bonjour !
 
Cette opération d'inclusion est rendue nécessaire à cause de l'appel à la fonction puts(). En effet, il est recommandé (et parfois obligatoire) de fournir au compilateur un prototype à la fonction utilisée

 
ben voila, arrange toi pour toujours fournir le prototype au compilateur c'est tout, meme si c'est pas obligatoire, c'est le C
c'est a cas que servent les fichiers d'en-tete
 
si le prototype d'une fonction n'est pas connu lors de son appel il peux y avoir des erreurs au niveau des types de parametres, le prototype aurait permis d'effectuer les conversions ou de degager une erreur

Oui, c'est bien ce que je pensais, c'est le role des fichies d'en tete... mais je ne vois pas l'interet de le declarer vu que c'est justement le role de ce fichier  

 
on insert le prototype de puts grace à la ligne '#include <stdio.h>', ou tu vois une déclaration de plus ?

dans ce cas non, Emmanuel le precise bien sur son site, c'est parfois obligatoire.... ce sont les cas qui correspondent au parfois qui m'interesse.
 

non mais si, la il est fourni le prototype ! et il n'est pas obligatoire
 
le prototype indique au compilateur (en plus du type retour) le type des arguments, lors de l'appel d'une fonction son prototype n'est pas obligatoire mais il est conseillé car il permet d'assurer le typage correcte des arguments (et donc entrainer des conversions ou erreurs de compilation)
quand Emmanuel dit qu'il est parfois obligatoire, je ne sais pas à quoi il fait allusion, il me semble qu'il est obligatoire en C99

C'est ce que j'avais compris...je voulais confirmation !
 
merci
 
je laisse le C99 de coté pr le moment lol