je voudrais apprendre a programmé en C.
j'ai déjà des connaissance de base, mais je cherche quelque conseil qui me permettent de mieux avancé, alors si on veut avoir un bon programmé en C, quel sont les chose nécessaire a faire et ne pas faire.
Version imprimable
je voudrais apprendre a programmé en C.
j'ai déjà des connaissance de base, mais je cherche quelque conseil qui me permettent de mieux avancé, alors si on veut avoir un bon programmé en C, quel sont les chose nécessaire a faire et ne pas faire.
Qu'appele tu programment en C ? Le langage C est un outil, un bon programmeur doit savoir bien programmer et bien programmer, c'est connaitre et savoir utiliser à bon escient des algos, ensuite le langage Utilisé n'est là que pour transcrire les algos ...Citation:
e voudrais apprendre a programmé en C.
Ou t'es tu arrêté ?Citation:
j'ai déjà des connaissance de base
Connaître ses limites est une bonne chose ! Ne pas essayer de bidouiller le code et savoir exactement ce que l'on fait est une bonne chose, ensuite, il y a des règles à bien suivre : bien nommer ses variables, effectuer des tests à chaque appel système, bien séparer les programmes en modules indépendants, éviter les "trucs" de hackers qui font gagner un cycle d'horloge sur dix minutes de calculs et produire du code le plus simple possible (plus c'est simple plus c'est facile à maintenir)Citation:
quel sont les chose nécessaire a faire et ne pas faire.
salut,
Je crois que l'algorithmie est très importante.
Connaitre les structures avancées c'est pas mal par exemple pourquoi utiliser une liste plutot qu'un tableau ?
Et a part certains points l'echelle du goret me semble un bon indicateur
:arrow: echelle du goret
C'est très exhaustif !!
j'ai regarder votre echelle de goret je n'ai pas compris ces points:
que signifie cette phrase "Utilisation d'expressions C non idiomatiques ".
quand on a pas le choix"Plus d'un return par fonction ".
ma question n'était pas la, je me pose la question si je vais faire un long programme, comment puise je etre sur que je ne vais pas devoir tous refaire après que je dépasse une centaine de ligne, quand je doit utiliser une macro, quand faire une fonction, comment découpé mon programme en plusieurs fonction sans perdre de son efficacité, est ce que une fonction qui appelle plusieurs fonction est une mauvaise chose, quand je doit faire pus d'un fichier, voila ce genre de question.
On en a parlé il n'y a pas si longtemps que cela et il en était ressorti que cette échelle était issue d'expérience purement personnelle et que certain points étaient presque discutables . D'ailleurs, j'ai l'occasion quelque fois de coder comme un goret en programmation système. (Emmanuel, je ne veux pas relancer la discution ... )Citation:
'ai regarder votre echelle de goret je n'ai pas compris ces points:
que signifie cette phrase "Utilisation d'expressions C non idiomatiques ".
quand on a pas le choix"Plus d'un return par fonction ".
Je ne pense pas que c'est un document qui peut t'aider. En revanche, les notes sont très utiles :
http://emmanuel-delahaye.developpez.com/notes.htm
Ensuite les conventions de codage sont tout aussi importantes (même si tu n'es pas obligé de respecter scrupuleusement tout ceci, ça reste indicatif)
http://emmanuel-delahaye.developpez.com/codage.htm
Pour finir avec les liens sur le site d'Emmanuel, je te recommande aussi ceci :
http://emmanuel-delahaye.developpez.com/complog.htm
En fait qu'appelle tu tout refaire ? En fait, ça n'est pas à cause du langage que tu devra tout refaire, c'est de la conception, et ça, ça ne se fait pas devant un clavier et un écran, c'est avec un papier et un crayon. Il faut absolument que lorsque tu code, ça ne soit que la dernière étape. Que tu n'ai pas à réfléchir sur l'agencement entre les modules. Parce que si cette reflexion se fait pendant que tu codes, tu es quasiment sur de faire n'importe quoi et produire du code qui ne sera pas bon.Citation:
je me pose la question si je vais faire un long programme, comment puise je etre sur que je ne vais pas devoir tous refaire après que je dépasse une centaine de ligne
Pour répondre à ces questions, il faut comprendre que les macros sont des éléments du préprocesseur et donc d'un simple analyseur de texte. Les fonctions appartiennent au langage. c'est le code qui sera compilé. Alors quand choisir entre l'un et l'autre ? Bonne question ! En fait, une macro c'est pour regrouper une ou deux instructions assez simple (MIN, MAX, ...), ou alors des instruction assez répétitives (allocations mémoire et vérification). Ensuite, il y a les personnes qui ne font que des macros ... ( même en cours, on a eu l'occasion de faire une liste chainée générique entierement avec les macros ...) mais, ça n'est pas une bonne chose parce que c'est long à écrire et mon lisible quavec des fonctions. Comme je te l'ai dis au premier post, privilégie la simplicité. Si tu dois passer une heure à écrire une macro, vérifier les effets de bords éventuels, c'est trop long (sauf si tu en vois une utilité primordiale pour ton programme).Citation:
quand je doit utiliser une macro, quand faire une fonction
Le cout d'un appel de fonction est on va dire assez dérisoire et il existe des mécanismes pour les éviter (inline et compagnie). Ca rejoint ce que je t'ai dis au premier post : si c'est pour gagner quelques cycles d'horloge sur un temps d'éxécution significativement plus long, ça n'est pas la peine. En revanche, si ta fonction est très courte, là utilise une macro.Citation:
comment découpé mon programme en plusieurs fonction sans perdre de son efficacité
Tout est une question de conception de tes programmes, il faut regrouper dans une fonction des instructions permettant d'effecuer une action bien définie (par exemple tu regroupes toutes les insttructions pour calculer une racine carrée dans une fonction racine).
De plus, tu as l'air d'avoir toujours en tête des problèmes de performance. Il faut savoir que l'optimisation est une des dernières phases du développement : tu fais quelque chose de fonctionnel dans un premier temps, tu utilise un profiler pour savoir quels sont les fonctions qui prennent le plus de temps et tu regarde ensuite comment les optimiser. Si tu commences par l'optimisation en premier, tu ne sauras pas quel est la partie qui ne fonctionne pas ; ton programme de base ou ton optimisation.
Mais n'oublie pas, l'optimisation par le langage de programmation ne représente qu'une infime partie de ton optimisation. La majeure partie de l'optimisataion concerne le choix des algos. Un tri par tas non optimisé (optimisations compilateur et langage) sera plus rapide qu'un tris par insertion optimisé sur un jeu de donnée assez conséquent.
Non pas du tout, le langage C est un langage de fonction, alors utilises les ! Quand tu dois effecter des E/S sur un fichier, tu ouvres le fichier, tu écrit ou tu lis dedans, et tu finis par le fermer, tout est fait avec des appels de fonction ...Citation:
est ce que une fonction qui appelle plusieurs fonction est une mauvaise chose
Un fichier par module indépendant. Tu ne fais pas un fichier par fonction. Tu regroupes sous un même fichier des fonctions qui ont la même utilité : fonctions mathématiques, fonction d'E/S. Pour ceci inspire toi de ce qui est fait dans la bibliothèque standard.Citation:
quand je doit faire pus d'un fichier,
:mouarf:Citation:
Envoyé par lastrecrue
Non sinon pour être à l'aise en programmation, un seul mot d'ordre : l'expérience :)
Si tu as le courage de te pencher sur un tuto, tu lis les bases et tu code toi même tous les programmes exemples.
Une fois que tu as toutes les bases, entraine toi à creer toi même tes petits programmes, puis quand tu seras fin prêt, étudie une API quelconque, par exemple pour developper un petit jeu, et si tu te fait plaisir, tu prendra la main 8-)
Il m'est déjà arrivée de coder un gros programme assez salement, puis qq mois (ou même pas), le recommencer complétement avec une nouvelle vision (plus pratique, plus performante, plus PROPRE). C'est vraiment qqch qui m'a bien permis de progresser. Pour des gros programmes, au début, c'est pas toujours facile de toujours prévoir tout d'avance, on fait des erreurs, on corrige assez salement, et au final, ça marche mais ce n'est pas terrible. Mais on peut analyser après coup toutes les erreurs qu'on a fait pour ne plus les faire la fois d'après.
Donc, l'expérience...
J'aimerai savoir comment vous procédez lorsque vous vous lancez dans un nouveau projet. Faites vous tout à la main, à savoir :
- Ecrire sur papier l'ensemble des fichiers
- Ecrire sur papier le nom des différentes fonctions et leur type etc...
Cela me parait difficile, il faut penser au programme avant de l'avoir conçu 8O
Quelque chose qu'on nous apprend pas à l'université, car nous sommes guidé fonction par fonction donc bon...
J'entend souvent parler d'UML et design paterns, cela s'applique-t-il aussi au C qui n'est pas orienté objet (même si on peux faire de l'objet en C) ?
Merci de vos indications, car j'ai souvent envi de me lancer dans mon premier GROS programme (interface graphique, utilisation de plusieurs bibliothèque etc...), mais je ne sait toujours pas comment m'y lancer (et je n'aime pas la programmation spontanée).
;)
C'est toujours pareil quelque soit le projet (aéronautique, technique), tu es obligé de penser à ton projet sans l'avoir vu.Citation:
Cela me parait difficile, il faut penser au programme avant de l'avoir conçu
Non, tu penses trop technique, l'ensemble des fichiers n'est pas important et ça n'est pas la première chose à penser. Il faut que tu penses au découpage de ton programme, les modules à créer et à utiliser.Citation:
Ecrire sur papier l'ensemble des fichiers
Ne fais tu pas de projets dans ton université ?Citation:
Quelque chose qu'on nous apprend pas à l'université, car nous sommes guidé fonction par fonction donc bon...
L'UML permet de présenter ton projet, c'est une formalisation de ton programme, ça aide à faire comprendre ce que tu fais mais ça n'aide pas à la reflexion sur ton programme ( mais je n'ai pas dis que c'était inutile).Citation:
J'entend souvent parler d'UML et design paterns, cela s'applique-t-il aussi au C qui n'est pas orienté objet (même si on peux faire de l'objet en C) ?
Les design pattern, ne sont pas interressant, c'est juste bon d'en connaître quelques uns (et encore ...), c'est à mon avis un truc de "geek" (désolé) qui ne te servira quasiment jamais en C. (On dirait que le terme a été inventé par des commerciaux, c'est génial ça fait tout, et en fait, c'est du vent car ce sont des pratiques que bon nombre connait et utilise en toute logique ...)
Si je peux te conseiller une chose avec un tel projet, utilises le modle MVC, c'est à dire séparer les données sur lequels tu travailles et ton interface. Ca permet de ne pas tout mélanger et ça te permet aussi de pouvoir changer d'interface graphique sans trop de problème.Citation:
interface graphique
Plusieurs techniques, j'utilises la plupart du temps l'analyse descendante. Tu liste grossièrement ce que doit faire ton programme, ensuite, tu essais de faire un découpage grossier de ton programme (j'ai besoin de faire tel ou tel module). Après tu regardes module par module quels sont les fonctions dont tu auras besoin (peut être t'as t'on parlé dans ton université de fonctions minimales). Et enfin, fonctions par fonctions tu regardes les algos à employer s'il y en a.Citation:
mais je ne sait toujours pas comment m'y lancer
La conduite d'un projet est un art difficile et, tu le confirmes, non enseigné.Citation:
Envoyé par _kal_
En fait, il n'y a pas de méthode rigide et rigoureuse, simplement quelques principes de bon sens qu'il convient d'appliquer, à savoir qu'il faut respecter une certaine séquence dans l'exécution des tâches.
En gros, et quelque soit le niveau, on doit suivre cette séquence :
- Définition (Quoi ?)
- Conception (Comment ?)
- Réalisation
- Integration
- Validation
1 - La définition traduit noir sur blanc les désirs du client. Les imprécisions et autres incohérences doivent être levées.
2 - La conception permet de spécifier les comportements sous la forme d'algorithmes et/ou de machines à états, et de découper le projet en unités plus petites (blocs fonctionnels ou BF). En gros, on arrive à un arbre dont les branches sont des BF de plus en plus fins. Dans un projet informatique pur, en gros, les feuilles sont les fonctions.
3 - Celles-ci sont ensuite codées et testées individuellement.
4 - Ensuite, on remonte d'un cran et on assemble les morceaux, on les fait communiquer on teste le résultat etc. Quand l'ensemble est assemblé, on a le produit. On le teste massivement (tests d'integration), et on corrige les derniers détails (interfaces, performances...).
5 - Enfin, le comportement du produit est comparé avec les exigences de la définition de celui-ci.
Ce principe de base bien connu (méthode en V) ne doit pas s'appliquer de façon brutale à un énorme projet, sinon, on risque de pertdre en visibilité, et de s'apercevoir au bout de 3 ans que le projet est trop coûteux ou qu'il utilise des technologies à la Star Trek...
C'est là qu'intervient la notion de méthode 'agile' (Comme eXtrem Programming, ou XP), qui considère qu'il faut au préalable découper le projet en une successions de mini projets cohérents (itérations courtes). Chaque itération nouvelle utilise la ou les itérations précédentes censée avoir été validée par la méthode en V.
Le but est d'avoir très rapidement (< 1 mois) un résultat tangible qui permet de valider et de corriger la définition et la conception du projet. Si un choix technologique se révèle inadéquat ou désatreux, on est prévenu plus rapidement, et on peut envisager une nouvelle orientation.
D'autres principes de XP sont interessants comme
- Le codage en binôme
- Le codage par les tests
- etc.
qu' est ce qu' une UML?Citation:
Envoyé par PRomu@ld
si non je me demande finalement pour le passage d'un niveau de conception a un autre par exemple pour la création d'un jeu pour passé du mode console en mode graphique, quel sont les étapes nécessaires pour avoir un beau résultat graphique, je pense a la SDL.
UML est un langage de modelisation qui permet d'exprimer differentes choses a propos d'un programme, dont:Citation:
Envoyé par lastrecrue
- sa structure statique
- sa structure dynamique
- le comportement temporel
- les cas d'utilisation
- d'autres choses qui m'echappent pour le moment.
Les diagrammes UML qu'on voit le plus souvent sont les premiers.
UML a ete developpe et est principalement utilise dans le cadre de methodologies de conception orientees objets, mais rien n'empeche de s'en servir dans d'autres contextes.
Tu sembles avoir percu l'essentiel de la nature des design pattern (ce sont des pratiques eprouvees) sans en percevoir les interets:Citation:
Envoyé par PRomu@ld
- le premier, c'est de leur donner un nom; ce qui permet d'en parler sans recourir a de longues descriptions ("a ta place, j'utiliserais une factory", c'est simple, ca va droit au but, "a ta place, j'utiliserais des classes virtuelles et une classe qui permet de construire les classes derivees, un peu comme on a fait dans le projet X", c'est ambigu, ca demande des explications complementaires ...)
- ce sont des pratiques qui ont ete etudiees en tant que telles, en cherchant a decrire le genre de problemes qu'elles resolvent (donc on a une forme canonique qu'on utilisera si on n'a pas de bonnes raisons de faire autrement, ce qui favorise l'uniformite et donc la robustesse, et une analyse de variantes possibles avec leur qualites et leurs defauts)
C'est un genre de bonnes pratiques de conception. Comme toute bonnes pratiques, ce n'est pas quelque chose de genial, c'est quelque chose que beaucoup faisaient plus ou moins consciemment. Mais il y a un interet a les utiliser de maniere consciente.
Maintenant, comme tout sujet qui a ete a la mode, il y a eu un usage marketing, il y a eu ceux qui ont cherche a mettre dans tous les programmes toutes celles du bouquin sans chercher a voir si elles s'appliquaient reellement a leur probleme, il y a eu ceux qui ont cherche a "inventer des DP" en partant de rien, sans remarquer que c'etait un non sens: une DP, c'est un schema recurrent dans la conception de programmes, on ne les invente pas, on les remarque apres les avoir rencontrees... Et comme toujours quand il y a une reflexion plus abstraite, ca peut etre aussi un moyen pour certains d'eviter de redescendre vers le concret.
Chose que je n'ai jamais fait et que je ne sais pas comment approcher. Un diagramme sagital peut-être ?Citation:
Envoyé par PRomu@ld
Si, mais ils sont tous guidés ; par exemple, on nous demande d'écrire la classe A, et on s'aperçoit qu'un jour elle finit par nous servir lors du codage de la classe C ;)Citation:
Envoyé par PRomu@ld
Je suis qu'en seconde année, donc peut être qu'un jour j'aurai un vrai projet à mener.
C'est peut-être ce qu'il me faudrai, car mon problème s'articule autout du découpage de mon programme, dont je ne sait aucunement comment aborder.Citation:
Envoyé par PRomu@ld
Je ne connais pas MVC, je vais googlé ça :PCitation:
Envoyé par PRomu@ld
Oui, cela se rapproche de la notion de méthode 'agile' décrite par Emmanuel. Il est préférable pour mon premier projet de m'orienter vers ce type de technique, afin d'apercevoir le bout du tunnel ;)Citation:
Envoyé par PRomu@ld
Ce type d'approche n'accentue pas les risques de bugs ? Je n'ai jamais réaliser de modélisation logiciel, et je pense à investir dans un livre à ce sujet. Peut être celui-ci correspondrait à mes besoins :Citation:
Envoyé par Emmanuel Delahaye
http://www.eyrolles.com/Informatique...rogramming.php
Ou celui-ci:
http://www.eyrolles.com/Informatique...rogramming.php
UML peut il réaliser le découpage que je cherche (et aussi en toute aisance) ?
C'est là qu'on se rend compte que savoir programmer est une chose, concevoir un logiciel en est une autre.
Ici, mon objectif est de porter un logiciel sous Linux, existant uniquement sous Windows. L'interface graphique reposera sur l'api GTK+-2.10. Ainsi, je connais déjà l'allure du logiciel, et ce qu'il réalise précisément. Ce qui me manque, c'est le découpage structurel.
C'est ça que je voulais dénoncer, le coté énormément marketing, les design pattern à une époque faisaient tout (presque le café ...), C'était comme un peu tout : tout le monde en parlait, mais personne ne savait réelement à quoi celà consistait (beaucoup on brassé du vent en les évoquant ...), mais tout le monde était d'accord : "c'est génial".Citation:
Envoyé par Jean-Marc.Bourguet
Oui, si on veut, le fait que les méthodes soient éprouvée est une bonne chose, leur donner un nom aussi, mais ça s'arrêtre là, pas la peine de créer un motif pour créer un motif (c'est surtout ça qui m'a embêter). Il faut en connaître quelques uns ( certains sont utilisés quasi quotidiennement sans en savoir le nom en fait ...), mais ne pas en faire tout un cinéma ...
Ne t'inquiète pas, théoriquement dès l'an prochain tu devrais avoir un projet à faire sur plusieurs semaines (ça se fait beaucoup en troisième année), tu auras l'occasion de sortir du cadre purement académique. (oui, entre parenthèse, on dis qu'a la fac, on est pas assez guidé,encadré, perso je trouve que c'est le contraire en fait, mais bon passons.)Citation:
Envoyé par _kal_
Il faut que tu essais de sortir quelques parties de ton programme indépendantes : penses aux questions suivantes : j'ai besoin de faire ceci, c'est cette partie qui doit le faire, ceci, c'est cette partie qui doit le faire.Citation:
Envoyé par _kal_
Les méthodes comme XP intègrent d'autres caractéristiques qui permettent d'éviter les bugs : travail en binome, test unitaires et de non régression ...Citation:
Ce type d'approche n'accentue pas les risques de bugs ?
L'un est plutôt technique, l'autre est théorique.Citation:
C'est là qu'on se rend compte que savoir programmer est une chose, concevoir un logiciel en est une autre.