Zeb's Ouaibe Site

Promouvoir et soutenir le logiciel libre

Site optimisé pour tout navigateur respectant les standards (c;

Développement C/C++

Table des matières

Outils libres

GCC (GNU Compiler Collection)

http://gcc.gnu.org/

Le compilateur C/C++ de vos rêves existe, il s'appelle GCC. Je pourrais m'étendre des heures sur ses qualités et capacités mais je résumerai ainsi : libre, éprouvé, en perpétuelle amélioration, multi plate-forme, multi-langage, compilation croisée et optimisation poussée du code généré. Je suis sûr d'en oublier mais bon, c'est déjà suffisamment alléchant comme cela, non ?

Bin Utils

http://sources.redhat.com/binutils/

Les développeurs utilisent le plus souvent cette collection d'outils sans le savoir, même si elle est essentielle pour eux. Les outils de cette suite permettent de manipuler les fichiers binaires, notamment ceux compilés par GCC. On y trouve par exemple l'éditeur de liens GNU ld et l'assembleur GNU as mais aussi bien d'autres utilitaires irremplaçables.

De manière plus générale, lorsqu'on développe sous GNU/Linux (ou Unix), il est utile de connaître les services offerts par l'ensemble des utilitaires GNU, dont certains sont très précieux. Pour vous en convaincre, jetez un oeil aux « fileutils », « findutils » et autres « diffutils » que vous trouverez dans le répertoire en ligne du projet GNU :

http://www.gnu.org/directory/GNU/

GNU Make

http://www.gnu.org/software/make/

On ne présente plus l'utilitaire Make, porté sur la quasi-totalité des plates-formes existantes. Même lorsque vous utilisez un environnemnt de développement intégré entièrement graphique, il n'est pas rare que Make automatise pour vous la compilation en arrière-plan.

La version GNU de cet utilitaire gagne à être connue car elle enrichit la syntaxe et les fonctionnalités par défaut de moult détails rapidement indispensables.

Autotools (Autoconf, Automake, Libtool)

http://www.gnu.org/software/autoconf/ http://www.gnu.org/software/automake/ http://www.gnu.org/software/libtool/

Au début, un petit Makefile bien léché suffit à votre projet. Mais lorsque ce dernier devient un tantinet complexe (arborescence touffue, fichiers à foison, langages et compilateurs multiples, etc), lorsqu'il doit être largement diffusé (donc portable, internationalisé et localisé), ou lorsqu'il fait appel à des briques particulières (rarement installées par défaut sur le système cible), l'écriture d'un Makefile efficace est une gageure.

A cet instant, on apprécie la puissance des Autotools. Au prix d'une poignée de fichiers de configuration qui se substituent à vos Makefile originels et décrivent l'essentiel de votre projet, de ses exigences et de ses dépendances, les Autotools se chargent de générer les Makefile et autres scripts nécessaires au déploiement et à la compilation de votre projet. Exécutés avant toute compilation, ces scripts évaluent l'environnement logiciel et système de la machine hôte et adaptent en conséquence le processus de compilation. Vous êtes ainsi libéré de tâches sans intérêt mais qui requièrent beaucoup de temps et d'énergie lorsqu'elles sont réalisées manuellement.

Les Autotools exigent un effort d'apprentissage mais le jeu en vaut la chandelle..

CMake

http://www.cmake.org/

Depuis quelques mois un ami me vantait les mérites de CMake. Pour ne pas mourir idiot, j'ai fini par le tester et j'ai été conquis. Oubliées la syntaxe absconse et plurielle des Autotools, la pléthore de macros aux noms fluctuants d'une version à l'autre. Si CMake peut paraître moins riche que les Autotools en modules additionnels prêts à l'emploi, il s'avère supérieur à bien des égards. A vrai dire, la seule chose à laquelle je n'arrive pas à me résigner, c'est qu'un script porte d'extension « .txt » (il paraît que c'est pour faciliter l'édition desdits scripts sur MS-Windows... voilà à quoi on en est réduit lorsqu'on veut développer sur une plate-forme bureautique). Quoiqu'il en soit, à l'avenir, je préconiserai CMake.

GDB (GNU Debugger)

http://sources.redhat.com/gdb/

Un compilateur comme GCC devait avoir un débogueur à la hauteur, GDB est né. Certes, c'est de la ligne de commande et on a fait mieux comme interface homme-machine depuis mais puissance et efficacité sont au rendez-vous. Quant à la dynamique du projet, elle n'a rien à envier à celle de GCC.

DDD (Data Display Debugger)

http://www.gnu.org/software/ddd/

Un Makefile aidant, vous vous contentez de GCC mais un débogueur en ligne de commande, c'est vraiment au dessus de vos forces : pas de panique DDD est là. Il s'agit d'un frontal graphique pour GDB qui se pilote au clic de souris et à l'oeil. Cet outil n'a rien à envier à ses homologues commerciaux, c'est parfois même le contraire (essayez pour voir la visualisation des chaînages de données).

Insight

http://sources.redhat.com/insight/

DDD, c'est peut-être sympa mais, allez savoir pourquoi, vous n'accrochez pas ? Pas de problème, essayez cette alternative séduisante qu'est Insight. Toujours libre, bien entendu !

Valgrind

http://valgrind.org/

Valgrind est un outil de débogage qui contrôle la validité des accès à la mémoire allouée dynamiquement par un programme ainsi que quelques autres aspects de son fonctionnement. Il vous signale bien évidemment toute fuite de mémoire (bloc alloué que l'on oublie de libérer). Pour les connaisseurs, c'est un peu l'équivalent du logiciel Purify mais en libre. Valgrind devrait faire partie de la boîte à outils de tout développeur C/C++ un tantinet sérieux et soucieux de produire un code propre.

Ce projet a été initié par un développeur de talent qui a trouvé une solution très élégante à un problème épineux et l'a brillamment implantée. Il a par conséquent très vite conquis ses pairs et attiré de nombreux contributeurs. De fait, ce projet est très dynamique, d'autant plus qu'aucune solution libre combinant autant de simplicité et de puissance n'existait jusque là.

LeakTracer est une alternative à connaître. Bien que plus rustique et moins riche, il est arrivé qu'il me fournisse des diagnostics plu pertinents que ceux de Valgrind.

Strace / Ltrace

http://www.liacs.nl/~wichert/strace/ http://packages.debian.org/unstable/utils/ltrace.html

ltrace est un utilitaire de débogage qui intercepte et affiche tous les appels aux bibliothèques dynamiques effectués par le programme qu'on lui demande de lancer. Il peut aussi détecter les signaux reçus par le processus. strace fait de même avec les appels système. L'un et l'autre ne nécessitent aucune compilation particulière du programme cible et s'avèrent précieux dans la résolution des bogues.

Diff / Patch

http://www.gnu.org/software/diffutils/ http://www.gnu.org/software/patch/

L'utilitaire diff analyse deux versions d'un même ensemble de fichiers et affiche l'ensemble des différences qu'il trouve. La sortie est produite sous un format qui permet de localiser de manière sûre ces différences et, si besoin est, de les traiter automatiquement par la suite. L'utilitaire patch utilise la sortie de diff (préalablement stockée dans un fichier) pour mettre à jour l'ancienne version des fichiers et les amener au niveau de la nouvelle. Après application du patch, il n'existe plus aucune différence entre les deux arborescences. patch permet d'économiser du temps, de l'argent et de la bande passante sur le réseau en ne transmettrant à l'utilisateur que les différences entre les deux versions des fichiers au lieu de l'intégralité des fichiers.

NB : diff n'est pas d'une grande convivialité et sa sortie est parfois difficile à analyser de manière certaine. Pour pallier ce problème, on peut utiliser l'un des frontaux graphiques disponibles, notamment TkDiff (présenté plus bas) ou Kompare.

Subversion, CVS et Git

http://git.or.cz/ http://subversion.tigris.org/ http://www.cvshome.org/

CVS et Subversion sont deux outils de gestion de version (et, incidemment de configuration). A ce titre, ils conservent dans un référentiel une copie de chaque version des fichiers d'un projet, peuvent à tout instant fournir une version précise de ces fichiers et montrer les différences entre deux versions d'un même fichier. Ils constituent en quelque sorte la mémoire du projet.

Lorsque le projet est confié à une équipe, CVS et Subversion assurent la distribution des documents (chaque membre récupère une copie locale du projet) ainsi que l'intégration des modifications effectuées par les différents membres.

Utiliser CVS ou Subversion ne présente que des avantages. Ils constituent par leur principe même un système de sauvegarde. Ils vous donnent le droit à l'erreur et la possibilité de retourner à un état connu du projet. Vous pouvez créer plusieurs branches évoluant indépendamment (très pratique lorsque vous devez maintenir simultanément plusieurs versions d'un même logiciel). De plus, CVS et Subversion ne se limitent pas au code ; ils peuvent très bien être utilisés sur des documents, voire intégrer des éléments binaires.

CVS est un ancêtre respectable qui a rendu de précieux services à des générations entières de développeurs. Mais il souffre de plusieurs défauts et manques fonctionnels pénalisants que la conception même de CVS ne permet pas de corriger (impossibilité de renommer les fichiers ou de les déplacer sans perdre l'historique de leurs modifications, mise à jour non atomique du référentiel, support quasiment inexistant des fichiers binaires, etc.). En 2000, plusieurs développeurs de CVS ont donc décidé de repartir de zéro et de développer un nouvel outil, reprenant la syntaxe de CVS mais offrant l'état de l'art en matière de gestion de version. Subversion était né.

Subversion ne fait pas que corriger les défauts de CVS, il apporte des fonctionnalités intéressantes telles que la possibilité de lancer des actions avant ou après l'acceptation d'une modification du référentiel. Des développeurs pourront s'en servir pour conditionner l'acceptation d'une modification par le succès des tests unitaires. Le mainteneur d'un site Web pourra faire en sorte que toute modification effectuée dans le référentiel soit automatiquement répercutée sur le site. Les perspectives sont nombreuses.

Subversion et CVS sont des référentiels centralisés et le principe même de tels référentiels peut poser problème. Le cas échéant, vous avez intérêt à opter pour un référentiel décentralisé tel que Git qui offre en outre divers avantages sur Subversion : meilleure gestion des branches et de leur fusion, référentiel bien moins volumineux, possibilité de supprimer de l'historique une version arbitraire d'un fichier, etc. À mes yeux, Git souffre encore de deux défauts. Le premier est d'associer à certaines commandes classiques un rôle différent de leur rôle habituel (j'aurais préféré une équivalence ou, à défaut, l'adoption d'un jeu de commandes propre à Git). Le second est l'immaturité des clients graphiques (même si j'ai une nette préférence pour la ligne de commande dans la plupart des cas, certaines opérations sont plus rapides et leurs résultats sont plus parlants lorsqu'elles sont menées par le biais de clients graphiques (cas de la commande diff).

TkCVS

http://www.twobarleycorns.net/tkcvs.html

TkCVS est une frontal graphique pour CVS et, depuis peu, pour Subversion. La ligne de commande de CVS n'a rien d'effrayant et elle me suffit la plupart du temps. J'ai cependant recours ponctuellement à TkCVS lorsque l'information gagne à être présentée graphiquement. Il en va ainsi de l'arbre des versions d'un fichier. Mais réduire TkCVS à cela n'est pas lui rendre justice. Il s'agit d'un outil complet et facile à maîtriser. Si vous n'êtes pas à l'aise avec la ligne de commande, n'hésitez pas un instant, TkCVS est fait pour vous.

TkDiff

http://tkdiff.sourceforge.net/

TkDiff est une interface graphique qui invoque le célèbre utilitaire diff pour comparer ligne à ligne le contenu de deux fichiers. TkDiff interprète la sortie produite par diff et la rend bien plus lisible et efficace. En effet, TkDiff colorise les différences selon leur type (ajout, suppression ou modification) et propose un affichage juxtaposé des deux fichiers. Si vous le désirez, TkDiff peut ensuite vous aider à fusionner les deux fichiers. Essayez TkDiff et vous deviendrez un inconditionnel de cet outil.

Bugzilla

http://www.bugzilla.org/

Bugzilla est une application web de gestion des bogues. Lorsqu'une personne, développeur ou simple utilisateur, découvre un bogue, elle peut vérifier dans la base de Bugzilla si le bogue a déjà été signalé. Si ce n'est pas le cas, cette personne utilise le formulaire en ligne pour émettre un rapport de bogue circonstancié. Par la suite, le chef de projet ou tout développeur habilité renseigne Bugzilla à chaque changement de statut du bogue (confirmé, assigné, affecté, résolu, contrôlé, clos). Ainsi, chaque personne concernée par le projet sait à tout moment ce qui a été corrigé, ce qui est en train de l'être et ce qui reste à faire. Grâce à ce type d'outil, on évite le travail en doublon et les tours de table hasardeux pour savoir qui fait quoi. Mais plus important, on n'oublie rien sous le tapis !

Doxygen

http://www.doxygen.org/

Doxygen est un outil de documentation automatique. Il s'appuie sur des tags spéciaux insérés et renseignés par les développeurs dans le code source pour générer à la demande une documentation à jour. Ce type d'outil est d'une grande valeur car, pour un effort minimal (renseigner les tags relatifs à l'API que l'on vient de modifier ou d'ajouter), on obtient une documentation de grande qualité, reflétant parfaitement le code existant. Doxygen peut générer différents types de document, ce qui permet d'avoir en toute circonstance le format le plus adapté au besoin (aide en ligne via une page de man ou une page web, impression, import dans un traitement de texte, etc.). Cerise sur le gâteau, couplé à GraphViz, Doxygen peut intègrer à la documentation divers graphiques fort utiles (diagrammes d'héritage et de collaboration, arbres d'appel des méthodes, etc.).

Splint

http://www.splint.org/

Splint est un analyseur statique de code C issu des dernières recherches universitaires dans le domaine. Il détecte un grand nombre d'erreurs d'implémentation et de failles de sécurité. La puissance de son moteur d'inférence le rend bien plus précieux et « intelligent » que d'autres outils tels que Flawfinder ou RATS. En effet, ces derniers se contentent de balayer le code à la recherche d'appels système dangereux et sont incapables de déterminer si ces appels sont entourés de toutes les précautions qui s'imposent. De son côté, Splint sait évaluer les interactions entre les lignes de code. Il peut vous indiquer que vous utilisez un pointeur sans vérifier au préalable s'il est valide alors que sa valeur provient d'une fonction pouvant renvoyer la valeur NULL.

Revers de la médaille, Splint est très suspicieux et déclenche beaucoup de fausses alertes (90 % sur les sources d'un serveur FTP que j'ai audité). Mais c'est la loi du genre, ne serait-ce qu'à cause du caractère indécidable de certaines situations. Du coup, ses rapports sont très volubiles et demandent une méticuleuse analyse. Heureusement, il est possible d'instrumenter le code en insérant des commentaires particuliers pour orienter Splint et lui demander d'ignorer localement ou globalement des constructions d'abord suspect.

Splint est un outil précieux lorsque vous souhaitez développer une application pour laquelle la sécurité est primordiale. Dans ce cas, utilisez Splint dès les premières lignes et instrumentez le code au fur et à mesure, sinon bonjour la migraine à la fin du projet ! Cet outil fait partie de la panoplie que j'utilise lorsqu'un client me commande un audit de code. Il demande un peu de pratique mais il rend de fiers services.

Indent / Artistic Style / Uncrustify

http://home.hccnet.nl/d.ingamells/beautify.html http://astyle.sourceforge.net/ http://uncrsutify.sourceforge.net/

L'utilitaire indent se charge de réindenter un ensemble de fichiers sources C de manière homogène et selon des règles précisées sur la ligne de commande. Ce faisant, il simplifie la maintenance des sources.

Plus récent et apparemment plus dynamique, astyle (Artistic Style) gère aussi le langage C++ (ainsi que les langages Java et C# mais cela ne m'intéresse guère).

Depuis quelques mois, je travaille sur un projet dont le code est nettoyé par Uncrustify. L'outil est puissant mais il nécessite la création préalable d'un fichier de configuration et le réglage d'un bon nombre de paramètres là où ces prédecesseurs utilisent des valeurs par défaut qui me conviennent parfaitement.

SLOCCount / Cloc

http://www.dwheeler.com/sloccount/ http://cloc.sourceforge.net/

SLOCCount est un petit utilitaire sympathique permettant de compter le nombre d'instructions d'un code source de manière plus intelligente qu'une simple commande wc. En effet, alors que wc compte les lignes du fichier, SLOCCount compte les instructions (qui peuvent s'étaler sur plusieurs lignes) et ignore les lignes blanches et les commentaires. SLOCCount reconnaît et traite une multitude de langages. Si le projet en utilise plusieurs, cet utilitaire effectue des décomptes séparés pour chaque langage. Pour finir, SLOCCount propose une évaluation de la charge (coût humain et financier) du projet via la méthode COCOMO. Au début, je prenais cela pour un distrayant gadget. Mais après avoir demandé l'évaluation de la charge de travail induite par plusieurs projets que je connaissais bien, j'ai du me rendre à l'évidence : il ne se trompe pas trop. Réellement surprenant...

Cloc est un outil inspiré de SLOCCount mais qui vise à éliminer ses défauts. C'est lui que j'utilise désormais.

GetText

http://www.gnu.org/software/gettext/

GetText est une bibliothèque et un ensemble d'outils qui permettent de localiser les programmes (i.e. rendre l'interface homme-machine multi-lingue).

En complément, je vous suggère d'utiliser poEdit, outil dont l'interface graphique facilite l'édition des catalogues de messages « .po » utilisés par GetText.

GenGetOpt

http://www.gnu.org/software/gengetopt/

A partir d'un fichier décrivant les options du logiciel, GenGetOpt génère automatiquement le code C gérant les options passées sur la ligne de commande. Il libère ainsi le développeur d'une tâche sans intérêt et répétitive.

[ Retour au début de la page ]

Documentation

Manuels des outils GNU

http://www.gnu.org/manual/manual.html

Comme la FSF fait très bien les choses, les manuels des outils libres du projet GNU existent et sont disponibles en ligne. De bash à GCC en passant par la bibliothèque C, vous trouverez votre bonheur sur cette page.

Cours de l'Institut Gaspard Monge

http://www-igm.univ-mlv.fr/~dr/Cours.shtml

On trouve ici de nombreux cours de programmation rédigés par les professeurs de l'Institut ainsi que de nombreux liens sur des ressources externes. Intéressant...

Cours d'initiation au C de A.D. Marshall

http://www.cs.cf.ac.uk/Dave/C/CE.html

Des cours d'initiation au langage C, on en trouve des tonnes sur le net alors pourquoi aller en chercher un en anglais ? Simplement parce que celui-ci est le plus complet que je connaisse (si vous avez mieux, je suis preneur).

Interfaces de communication sous Unix (par Gilles Roussel)

http://www-igm.univ-mlv.fr/~roussel/INTERFACE/index-frame.html

Un cours complet sur l'art de faire communiquer des processus et des machines sous Unix.

Guide de Beej sur la programmation réseau

http://beej.us/guide/bgnet/

Tout savoir sur l'utilisation des sockets sous Unix. L'auteur complète et met à jour régulièrement cette documentation des plus utiles. A noter : pour les anglophobes, Charles Vidal a traduit ce guide en français et le texte est disponible à l'URL suivante :

http://vidalcharles.free.fr/lf/socket.html

Dommage que la version date un peu...

Wotsit's Format

http://www.wotsit.org/

Ce site propose une description d'un nombre impressionnant de formats de fichiers classés par thème. A connaître lorsqu'on vous demande de coder des fonctions d'importation ou d'exportation !

[ Retour au début de la page ]

Copyright © 2001-2015 Sébastien Dinot
Licence Creative CommonsSauf mention contraire, les documents de ce site sont publiés sous licence Licence Creative Commons Attribution 3.0
Dernière modification : 2015-09-14 20:20:01 UTC
Dernière version : http://sebastien.dinot.free.fr/liens_dev_c_cpp.html