Forum Programmation.c Conception de gros projets en C

Posté par  .
Étiquettes :
0
24
jan.
2005
Bonjour à vous tous,

Depuis quelques temps, je développe en C. J'aimerai pouvoir réaliser des applications dans ce langage de la manière la plus propre possible à savoir, comme les grandes applications (Mozilla, OpenOffice.org, ...).

J'entends par là :
- Phase de génie logiciel / Conception de l'architecture
- Gestion de fichiers de langues (support des variables d'environnement LC_*)
- Parsing du fichier de configuration avec Flex et Bison
- Développement d'une application modulaire avec possibilité d'y greffer des plug-in
- Avoir peut-être un mini-langage relatif à l'appli (genre comme Vim)
- Support "propre" des erreurs

...etc. Bref, comment fait-on une grande application digne de ce nom ? Il y a-t-il une doc qui regroupe la description de toutes ces technos pour avoir une sorte de document de base "HowTo develop big projects en C in Linux/Unix environment·" ?

J'ai beau cherché, j'ai rien trouvé... Avez-vous une idée ?

  • # wikibooks

    Posté par  . Évalué à 1.

    Il y a un livre en cours d'écriture sur la programmation, assez ambitieux, et qui couvre tous les aspects que tu énumères et bien plus encore (en français en plus).

    Bon avant d'y aller, je te préviens quand même que c'est encore loin, très loin, d'être complet. En tous les cas, c'est ici que j'ai découvert LE langage de programmation ultime : le BrainFuck.

    Sinon plus sérieusement, ce que tu cherches semble être se qu'on apprend pendant de longues années dans toutes les universités ou écoles d'ingénieurs du monde. Et encore, j'en connais certains, qui même après avoir suivit se cursus ne savent toujours pas coder (ok, je digresse).
    --
    Thierry
    BF Lead Architect

  • # Mauvais exemples

    Posté par  (site web personnel) . Évalué à 5.

    Mozilla et OpenOffice sont developpes en C++. Apres il y a peut etre des bouts de C.

    Pour ma part je pense que le C en dehors de quelques applications specifiques a vecu. Faire des malloc de char * c'est franchement d'une autre epoque et ca ne devrait plus exister de nos jours.
    D'ailleurs au sujet de: Support "propre" des erreurs
    les languages recents proposent tous ce genre de chose.

    Pour developper de grosses applications, maintenant on a des outils bien plus performants que le couple vi/C: UML, OCL (on commence a y venir cf http://www.key-project.org/(...) ), programmation object... Il suffit de voir des outils comme Borland Together pour comprendre.

    Perso j'ai commence a programmer en C et en GTK+, ba j'ai vite compris qu'en utilisant Java ou meme C++/KDE/Qt (d'autres proposerons Python, Ruby...) j'etais beaucoup plus productif, que j'obtenais un code plus propre, plus clair, plus simple, moins de bugs ect...

    Pour s'en convaincre c'est d'ailleurs assez simple, GTK reprend le principe de la programmation object malgre etre programme en C. Autant donc utiliser directement un language object et ne pas re-inventer la roue.

  • # Directories

    Posté par  . Évalué à 1.

    A défaut de doc, tu peux toujours chercher sur freshmeat/gnu dir/sf... dans les catégories développement ? Bon, c'est sûr tout n'est pas regroupé. Par exemple cscope, un outil indispensable pour trouver des symboles dans des tonnes de sources (intégré à divers IDE), des outils UML pour la modélisation (génie logiciel ? un peut pédant comme mot à mon goût), guile est un intérpréteur Scheme (donc langage simple et extrèmemen puissant) destiné à servir de scripting pour les applis C notamment, sinon tu peux toujours utiliser des plugins en c avec dlopen et co (man dlopen) ou en utilisant la lib + portable de la libtool. Pour le support propre des erreurs (comme pour tout le reste), tout dépend des préfèrences de chacun (errno !!!, setjmp/longjmp pour faire des macros TRY/CATCH :p, valeurs de retour, ...).
    En fait tout dépend du style des coders.

    A noter : les GNU coding standards qui sont peut-être ce que tu recherche :
    http://www.fsf.org/prep/standards/(...)

  • # Digression : Conception vs Realisation

    Posté par  . Évalué à 2.

    Selon moi, trop anticiper la conception, c'est condamné son projet à manquer de dynamisme, à être figé ... mais foncer directement dans la réalisation, c'est le condamné à partir en vrille, l'envoyer dans des impasses couteuses en temps, avancer à l'aveuglette donc ...

    Ce que je veux dire, c'est que ma faible expérience de petit amateur du dimanche (=protection anti-puristes ON) me suggére que conception et réalisation doivent à la fois s'opposer et se compléter, que l'on doit avancer l'un juste de quoi avancer l'autre, que conception et réalisation doivent s'alterner fréquement, par période de taille appropriée (on avance l'un juste ce qu'il faut pour continuer l'autre, et ce en boucle). Ce qui permet de donner tout ce qu'il faut de dynamisme à son projet mais en sachant toujours vers où on va.

    Qu'en pensez vous ? Ferais-je erreur, devons-nous planifier, architecturer, schématiser tout à 75-95% avant de commencer à coder, ou devons-nous oublier toute cette paperasse pour nous précipité dans le code ?

    En bref, je déteste la paperasse, mais je la trouve indispensable pour conserver une abstraction de l'historique de développement du projet, et pour offrir un fil directeur au developpement dans un futur proche. Le code/concret d'un coté, la paperasse/abstrait de l'autre, mutuellement indiscociables et indispensable à la vivacité de l'avancé du projet.

    J'en viens donc à : je me demandais s'il existait des approches (méthodes, bouquins, sites, docs quelconques) qui se rapprocherai de ma perception, qui irait dans mon sens, afin que je m'instruise sur le sujet, si ça existait ? (il est hors de question que je change d'approche, je préfére appronfondir et formaliser celle que j'ai adoptée naturellement, même si minoritaire ...)

    • [^] # Re: Digression : Conception vs Realisation

      Posté par  (site web personnel) . Évalué à 4.

      Le concept que tu décris est appelé méthode itéréative, basée sur des cycles courts et répétitifs, et est caractérisitiques des méthodes dites "agiles", en gros les méthodes à la mode actuellement comme Extrem Programming (XP) ou encore Rational Unified Process (RUP)
      Ces méthodes veulent pouvoir profiter des retours d'implémentations pour modifier la conception, faire évoluer les besoins.
      Tu trouveras pleins de bouquins sur ces méthodes uqui ne se limitent pas aux itérations mais sont beaucoup plus complètes.
      Ces méthodes "modernes" s'opposent au bon vieux cycles en V (mappé sur tous les projets d'ingénierie comme dans le bâtiment) ou tu conçois tout d'un coup, tu réalise tout d'un coup, et tu pleures à la fin parcque celà n'a rien à voir et y'a rien qui marche.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.