Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
En pratique : La boîte à outils du développeur sur AmigaOS 68k
(Article écrit par Mathias Parnaudeau et extrait de GuruMed.net - janvier 2003)
|
|
Si vous avez suivi les deux articles sur GCC (1,
2), vous devez
être en pleine possession de cet environnement. Vous avez même certainement pu compiler quelques programmes de
votre cru ou des sources récupérés sur Aminet. C'est parfait, il ne reste plus qu'à bien s'entourer pour
devenir efficace.
Premiers conseils
On ne le répétera jamais assez : malgré l'ardeur, la précipitation n'est pas bonne compagne du programmeur,
même dans l'urgence. La pression peut être bénéfique mais rien ne vaut la réflexion et un code propre pour
des résultats robustes et durables.
La première chose à faire, que se soit pour écrire son code ou pour s'assurer qu'il fonctionne sans défaut,
est de se munir d'outils faits pour vous aider, mais dont on ignore parfois totalement l'existence.
Au niveau documentation, il est impératif d'avoir à portée de main un ouvrage de référence sur le langage
choisi. Pour les programmeurs C, nous retiendrons bien sûr l'incontournable "Langage C" par ses concepteurs
Kernighan et Ritchie, ainsi que "Méthodologie De La Programmation En C" par Jean-Pierre Braquelaire. Ils
ont comme intérêt principal la présentation du langage lui-même, de façon complète et didactique.
Réunissez aussi un maximum de livres, d'articles ou d'exemples concernant l'API des fonctions du système ou
des bibliothèques annexes (MUI, Picasso96, CyberGraphX, réseau, SDL...). Dans le même ordre d'idées, Internet
fourmille de ressources sur les technologies ou algorithmes que vous utiliserez pour prendre connaissance
du domaine dans lequel vous allez oeuvrer ; il serait extrêmement dommage de s'en priver. Prévoir enfin un
petit dictionnaire anglais/français qui pourrait bien être utile ! On le voit, programmer nécessite aussi
une base bassement matérielle, avant même d'élaborer le moindre plan d'attaque.
L'art de l'ASCII
Un programmeur se trouve bien souvent face à un éditeur de texte à jouer avec les caractères. C'est pourquoi
il est impératif de se munir d'un éditeur avec lequel on se sentira à l'aise. EditPad (livré avec AmigaOS 3.9)
a bien failli me décourager :(. Il en existe des dizaines, tous avec leurs défauts : trop simples, peu
ergonomiques, payants, bogués... Sans vouloir trouver le mouton à cinq pattes, choisissez celui qui vous
convient bien. Tout dépend pour cela de vos critères de choix : gestion des tabulations, coloration syntaxique,
possibilité de macros, navigation et raccourcis, rapidité, pliage de texte, etc.
Cela pourrait être GoldEd (disponible dans une version gratuite) ou CygnusEd pour les plus souvent cités.
Il y a aussi Emacs/MEmacs ou Vim, plus orientés Unix, sans doute plus complets mais plus difficiles à
appréhender. On doit encore pouvoir trouver AZur... ou plus simplement l'éditeur de votre environnement
de développement, comme StormC (qui utilise depuis sa version 4 le compilateur GCC).
Je passe volontairement l'étape de conception du projet qui demande principalement une bonne pile de papier
et un stylo. Pour mettre au propre, nous pourrons compter sur... votre éditeur :). Conservons justement
notre attention sur lui : chaque programmeur adopte pour ses sources ses propres conventions lorsqu'il
travaille. Citons par exemple le placement des accolades, la gestion et la taille des tabulations et leur
remplacement éventuel par des espaces, le style de notation des commentaires, etc. En consultant les
sources des autres (ce qui est vraiment instructif) pour les faire évoluer ou pour les étudier, l'envie
de réorganiser le code se fait de plus en plus pressante au fur et à mesure de la lecture. Que les sceptiques
essaient et me disent si ce n'est pas vrai. Ce travail est très fastidieux si on désire en effet reformater
le texte à sa façon ; mais encore une fois, il existe un outil pour s'en charger : Indent !
Il nous vient du monde Unix libre : vous trouverez d'ailleurs une version sur
Aminet (fournie par l'auteur de GoldEd) et une
autre dans une archive sur le site de
GeekGadgets,
avec les sources, bien entendu. Vous pourrez même utiliser ces dernières (les sources d'Indent) pour
constater de quoi Indent est capable : la boucle est bouclée. :)
Il propose par défaut la notation GNU qui sous-entend de nombreuses options, à vous d'ajouter les options
qui feront la différence. En parcourant la documentation, je vous conseille de noter au fur et à mesure ces
différences que vous comptez adopter par rapport au style GNU. Votre ligne de commande standard se constituera
ainsi d'elle-même. Elle peut devenir assez longue et nécessiter un alias. Prenez le temps de tout étudier en
détail, pour une heure passée à cette configuration, vous en gagnerez bien plus à l'usage.
Vérification du code
On n'y pense que rarement, ou on n'y tient pas, mais la lecture de son code par quelqu'un d'autre est des
plus bénéfiques ! Cela permet de revenir sur l'architecture, la lisibilité, les techniques employées, etc.
avant qu'il ne soit trop tard ! Si tel était le cas, je vous renvoie à l'introduction de cet article :).
Pour rappel, le compilateur vérifie lui aussi votre code, puisque s'il contient des erreurs, il refuse de
le compiler ou indique des alertes. Il est donc votre premier relecteur ! Avec GCC, des options comme "-ansi",
"-pedantic" ou "-Wall" peuvent vous en dire plus et même vous amener à revoir votre jugement sur la qualité
de vos travaux. De son côté, vbcc possède l'option "-c99" qui signale quelques alertes en plus, comme
l'utilisation d'une fonction sans prototype. Et encore, ce n'est rien à côté de la terreur des
approximations, la Madame de Rotschild des bonnes manières de la programmation en C : lclint, dont vous
trouverez les informations officielles sur lclint.cs.virginia.edu.
Je vais vous livrer quelques astuces puisqu'aucune documentation n'est incluse dans l'archive, qui ne
comporte que trois fichiers : lclint (1,2 Mo tout de même !), lib/ansi.lcd, setup. Pas un "Readme", pas un
guide : la zone, quoi ! Il faut lorgner du côté du setup qui nous donne une maigre piste :
setenv LCLINT_CPPCMD netinclude:/bin/cpp -P
setenv CPPINCDIR include:
setenv LARCH_PATH PROGDIR:lib
|
Il est indispensable d'adapter ces trois uniques lignes pour votre configuration et de les ajouter à votre
user-startup (ou à créer dans le volume "ENVARC"). Sachant que j'ai copié lclint et ansi.lcd dans "C"
en me passant du sous-répertoire "lib" au passage, mes réglages personnels sont :
setenv LCLINT_CPPCMD GG:bin/cpp
setenv CPPINCDIR GG:os-include
setenv LARCH_PATH SYS:C
|
Il semble que lclint trouve tout seul le répertoire des fichiers d'en-tête dans l'environnement GG et
ne nécessite pas absolument la variable "LARCH_PATH", mais puisqu'on a décidé de faire propre. :)
A chaque "première fois" que vous l'utiliserez, une boîte de dialogue va s'ouvrir, vous demandant d'assigner
le répertoire ".". N'ayez crainte et cliquez donc sur "Assign" puis "Ok", ce qui aura pour effet de l'associer
au répertoire courant.
Que fait lclint ?
Il veille sur les erreurs classiques d'utilisation de la mémoire désallouée ou de non-libération (fuite mémoire).
Il se défend aussi bien avec les problèmes de déréférencement de pointeur, les macros douteuses, les boucles
infinies, les valeurs de retour de fonctions ignorées, les risques d'incohérences sur les types, etc.
et autres joyeusetés !
Un petit fichier de mon cru et faisant preuve d'une incompétence certaine ne signalait qu'une seule alerte
avec l'option "-Wall" de GCC, alors que lclint m'a inondé de 38 erreurs. Et encore, sans utiliser les
informations du fichier ansi.lcd qui lui vient en aide !
Lclint est lent mais très efficace et même plus qu'on ne souhaiterait : il vous briserait une vocation de
programmeur ! Mais ne nous affolons pas, chaque alerte peut ne pas apparaître en lui passant l'option adéquate
au moment de l'exécution. D'autre part, lclint possède quatre modes, allant de "laxiste" (mais ça reste lclint ;))
à strict, les vérifications effectuées pour chaque mode sont visibles avec la commande :
Pour donner un ordre d'idée, sur un autre source, lclint indique huit erreurs en mode "weak", 28 en standard et...
123 en strict ! On peut donc y aller crescendo. Enfin, ce qui est intéressant (et fort à la fois) c'est qu'il
travaille uniquement sur les sources, sans que le programme soit compilé (pas de risque de planter le système).
Il remonte les fichiers d'en-tête et fait son boulot jusqu'au bout : un vrai pro !
Débogage
Une petite visite dans le répertoire debug d'Aminet va vous faire
tourner la tête tellement il existe d'outils pour suivre les appels systèmes et la gestion de la mémoire !
Mais comme pour les éditeurs, il va falloir trier. Autant l'avouer tout de suite, je n'ai pas tout testé !
Tous s'accordent à dire qu'une dizaine se détache du lot, les indispensables. Pour d'autres tâches plus
spécifiques, d'autres outils seront sans doute plus adaptés.
Mais avant de les présenter, sachez qu'il y a d'abord les non-débogueurs, que l'on devrait rencontrer sur
le Workbench de chaque amigaïste, à savoir SnoopDOS
et Scout, qui permettent, entre autres, de traquer les actions
du système ou l'état de ses ressources. Idéal pour voir à quoi un programme tente d'accéder, s'il oublie
de libérer un fichier, etc.
Nos outils de débogage utilisent la plupart du temps la MMU, et se nomment :
- Enforcer (avec de nombreux apparentés comme CyberGuard) pour capturer les accès illégaux, comme la
lecture ou l'écriture dans les zones mémoires inexistantes et non autorisées (les premiers kilos-octets de la RAM).
- MungWall pour déboguer les allocations mémoire et lecture/écriture dans les zones non allouées (nuance :)).
- WipeOut qui officie dans la même voie, tout comme PoolWatch plus spécialisé lui, dans
la gestion des pools mémoire. WipeOut permet aussi de détecter quand un programme ne libère pas toute la
mémoire allouée.
- SegTracker pour savoir quelle partie du code a fourni le "hit" (alerte).
- FindHit/GccFindHit qui utilisent des informations données par SegTracker pour mettre en évidence la ligne
fautive de votre code ! Pour vbcc, l'équivalent est FindHunkOffset.
- PatchWork pour signaler une mauvaise utilisation d'une fonction système.
- Sashimi : sert uniquement à rediriger les sorties de débogage destinées au port série dans une console,
tout comme son précurseur Sushi.
- MuForce (avec la mmu.library) : détecte les accès à des régions mémoire non disponibles. Permet d'obtenir
le code désassemblé.
- MuGuardianAngel : couplé à MuForce, il remplace le duo Enforcer/Mungwall.
- APurify lie l'exécutable avec une bibliothèque de débogage et utilise donc une autre approche pour
mettre en évidence les problèmes de ressources.
Le mode "-g" (en plus de "-hunkdebug" pour vbcc) ou "debug=all" avec SAS/C inclut des informations qui vont
permettre de cibler l'erreur qui survient à l'exécution : il est donc vivement conseillé de compiler ainsi
pendant la phase de développement, même si l'exécutable voit sa taille décuplée (tel l'incroyable hunk ;-)).
Je passe volontairement sur les débogueurs bas niveau et difficiles à appréhender, tels GDB, COP ou BDebug.
Concernant le compilateur C vbcc, je ne connais pour le moment ni les réglages, ni les outils spécifiques.
Je vous recommande quoi qu'il en soit un usage immodéré de SegTracker, Sashimi, GccFindHit, MuForce/MuGuardianAngel
(les MuTools), APurify, Enforcer/MungWall, WipeOut, PatchWork. A noter toutefois que MuGuardianAngel, WipeOut
et Mungwall ralentissent le système donc il peut devenir inconfortable de les laisser en permanence.
Les documentations et les options sont généralement très fournies. Encore une fois, leur lecture représente
un investissement mais il paraît difficilement concevable de développer correctement sans utiliser ces outils.
Un programme fournissant des "hits" (affichages d'erreurs style Enforcer) ne devrait pas être distribué !
Non à l'insécurité
Même s'il ne développe pas, tout amigaïste devrait avoir à disponibilité : SegTracker + Enforcer & MungWall/WipeOut
(ou MuForce & MuGuardianAngel) + Sashimi. Leur usage permet de fournir des informations aux développeurs et de
prévenir une instabilité du système. Les "hits" ne sont pas annonciateurs de bonnes nouvelles.
Il est regrettable qu'il n'existe pas de solution prête à l'emploi pour les non-programmeurs, qui pourraient
ainsi stabiliser leur système sans connaître le détail de ces outils.
J'ai insisté sur lclint que presque personne n'utilise mais qui est extrêmement puissant.
|
