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
|
|
|
|
Test de StormC 2.0
(Article écrit par Brice Fromentin et extrait d'Amiga News - octobre 1997)
|
|
StormC 2.0 est la nouvelle version de l'environnement de développement ANSI C/C++ Amiga de Haage & Partner.
Installation
L'ensemble se présente avec sept disquettes et un manuel en anglais de 200 pages. A première vue, il semble qu'un environnement
nécessite plus, mais sans à priori, je lance l'installation.
Sans problèmes apparents, il installe différents correctifs pour que son fonctionnement soit parfait. Noter qu'il propose
d'installer GoldED 4, un éditeur de texte fournit, pour le travail sur les sources. Le logiciel Installer d'AT (pardon AI :))
remplit merveilleusement son office. De plus, dans la documentation, on nous explique comment désinstaller complètement StormC.
Je démarre, et StormC s'ouvre sur mon Workbench. Pas de chance car je lui avais demandé de le faire sur son écran. Je lance le
"ScreenManager" et je vois que l'écran configuré l'était mal, donc je lui donne une résolution capable de s'ouvrir. Ensuite
je vais dans les types d'outils de l'icône de StormCPP pour changer "PUBSCREEN=STORMC" en "PUBSCREEN=StormC". Et oui, on ne
rigole pas avec les noms d'écran public. Enfin, Il s'ouvre sur son écran, mais mes surprises ne s'arrêtent pas là car en voulant
ouvrir une fenêtre de texte, devinez... Elle s'ouvre sur mon Workbench :(. Donc rebelote, mais avec les préférences de GoldED.
L'installation enfin terminée, je vais pouvoir commencer mon investigation. Notez cependant qu'une résolution de 640x256
est trop faible pour pouvoir travailler.
Premiers pas
Les couleurs adoptées par l'environnement sont les maintenant célèbres couleurs de MagicWB, du fait du clonage de mon Workbench
pour l'ouverture de l'écran de StormC par le ScreenManager. Une barre d'outils apparaît, rendant accessibles les principales
fonctions de gestion d'un projet. Il aurait été souhaitable que cette barre d'outils soit configurable ; sur les environnements
modernes, ce genre de "gadget" est fort apprécié pour augmenter sa productivité.
Dans mon élan, j'ouvre un exemple (un projet). La requête ASL me demande de choisir mon projet. Elle est localisée dans le
répertoire StormSYS. Un choix plus judicieux aurait été de s'ouvrir dans le tiroir "Exemples" ou mieux, de sauvegarder dans
un type d'outils (ou autre), le chemin d'accès au répertoire contenant les projets. Je sélectionne donc l'exemple "ColorWheel"
qui ouvre sa fenêtre de projet décrivant ainsi le contenu de ce dernier. Cette fenêtre présente l'intérêt de rendre accessibles
rapidement toutes les ressources utilisées par le projet, un très bon point, car dans les projets complexes il sera plus facile
de s'y retrouver. J'appuie sur le gadget "Run", le projet compile sans accrocs et rapidement, l'application se lance sans
surprise.
Comme le montre la figure 1, la coloration de la syntaxe est présente ce qui améliore la lisibilité. Notez que l'éditeur StormED
permet le choix des couleurs pour les types de textes reconnus. Cependant, la palme revient à GoldED qui permet de définir des
catalogues de syntaxes.
Le compilateur
Au choix, vous pouvez l'utiliser via l'environnement intégré ou par le CLI grâce à la commande StormC se trouvant dans le
répertoire "STORMC:StormSYS". Les réglages du compilateur peuvent être observés dans la figure 2. Rien de révolutionnaire
dans ces derniers, mais que de l'efficace, ce qui ne gêne en rien évidemment. Tout de même, la possibilité de sortir du code
68060 est un plus indéniable. Cependant, il y a neuf niveaux d'optimisations différents alors que seuls six sont disponibles,
pourquoi ne pas avoir modifié la glissière de façon à ce qu'il ne puisse avoir que six niveaux ?
Comme le but du compilateur est de générer du code, voyons donc de quoi il en retourne avec ce dernier en mode d'optimisation
6 (le meilleur disponible). Tout d'abord, le source que StormC nous fournit est documenté, ce qui est un très bon point pour
la compréhension. Cependant, le niveau 6 d'optimisation reste décevant sur quelques détails :
; if (IntuitionBase = Openlibrary("intuitionlibrary",39))
move.l _SysBase(a4),a6 ; Il faut bien le préciser
moveq #$27,d0 ; Pas de problème non plus
lea L36(pc),a1 ; OK
jsr -$228(a6) ; OpenLibrary
move.l d0,_IntuitionBase(a4) ; Sauve Résultat
tst.l _IntuitionBase(a4) ; Ligne inutile
beq L91 ; Saut Conditionnel
|
Comme je le précise dans le fragment que je commente ci-dessus, il y a une ligne complètement inutile du fait que le "move.l
d0,_IntuitionBase(a4)" effectue de lui-même le test "tst.l _IntuitionBase(a4)". Cet exemple est le premier piège d'optimisation
dans lequel StormC tombe. Mais, s'il n'y avait que celui-ci... Suit dans le source :
; if (GfxBase = OpenLibrary("graphics.library,39))
move.l _SysBase(a4),a6 ; Inuble car déjà avec cette valeur
[...]
|
Le second piège est la vérification des valeurs contenues dans les différents registres du processeur. Dans le cas d'AmigaOS,
des règles strictes régissent ces derniers. Dans l'exemple cité, le registre A6 contient la base de la bibliothèque appelée et
reste inchangé après un appel à une fonction de cette dernière. Enfin, pour les problèmes d'optimisation les plus importants,
le code est efficace et concis.
Autre point important, les données de débogage qui sont ici placées dans un fichier à part. Cette solution est une réponse
appropriée à un problème rencontré dans beaucoup de langages qui fusionnent le programme et les informations de débogage.
En effet, StormC assure par cette méthode la similitude de fonctionnement entre les versions "DEBUG" et "NODEBUG".
De plus, il n'y a plus besoin de compiler une fois de plus pour obtenir la version définitive du fait qu'elle existe déjà.
L'éditeur de lien
Cette drôle de petite bête est censée combiner les différents modules d'un projet pour fournir le programme tant attendu.
En fait, afin de gagner du temps dans la maintenance d'un projet et aussi dans son temps de compilation, on sépare souvent
un projet en plusieurs modules. La figure 3 nous montre que StormLink possède son lot d'options. La plus intéressante reste
sans doute le fait de pouvoir créer une vraie bibliothèque partagée le plus simplement du monde. Notons aussi la possibilité
de lier un fichier en provenance de StormWizard, générateur d'interfaces graphiques. A part ceci, que du standard qui
fonctionne proprement et rapidement.
Le débogueur
Il est un fait acquis : on n'est pas parfait et donc, par cet axiome, nous faisons des erreurs qu'il va bien falloir que nous
corrigions. StormC fournit donc un débogueur afin de partir à la croisade contre les bogues. L'interface du débogueur est
concise et va droit au but. Remarquez sur la figure 4, que l'éditeur de source s'adjuge une colonne à gauche du source afin de
signaler les points d'arrêt. Mais pour vraiment nous aider, StormC nous offre des outils performants qui fonctionnent en équipe
avec le débogueur pour améliorer l'efficacité de ce dernier. On peut voir dans la figure 5 que les outils suivant apparaissent
au gré de la volonté de l'utilisateur :
- La fenêtre des variables.
- La fenêtre des points d'arrêt.
- Un éditeur de mémoire en hexadécimal.
- Un désassembleur.
La fenêtre de variables permet de surveiller le contenu des variables et tout ce qui les concerne (type, données structurées...).
Cependant, il reste impossible de changer les valeurs de certains types et pour cela, il vous faudra donc ruser en changeant le
type puis la valeur et en restaurant le type pour ne pas trop perturber l'exécution.
La fenêtre des points d'arrêt ne souffre, quant à elle, d'aucun défaut du fait de la simplicité des données qu'elle doit gérer.
L'éditeur de mémoire hexadécimal remplit son office humblement. Il aurait été intéressant que des fonctions de recherche lui
soit ajoutées mais il n'en est pas cas...
Le déassembleur poursuit un peu la même philosophie que le débogage des sources, il permet d'afficher ou non les instructions
"Illegal" afin de se passer des inclusions du débogueur pour son fonctionnement. Lui aussi, très succinct, est loin d'un Monam
ou Barfly. La phase de débogage est rendue très agréable grâce au "Ressource Tracking" (pistage des ressources)
qui permet de couper la tâche dès que l'on a repéré l'erreur.
Les problèmes
Fort d'une impression générale assez bonne, je me lance dans la lecture du manuel en français traduit par ADFI. La traduction
somme toute satisfaisante semble néanmoins parfois fantaisiste tout en ne nuisant pas trop au sens du contenu. Le papier est
de moins bonne qualité que la version anglaise et fait 20 pages de moins (qui a dit que le français est moins concis que l'anglais :))
dû à l'utilisation de toutes petites polices alors que le manuel original arbore des tailles de caractères plus lisibles.
Autre constat de cette documentation, comment fait-on pour programmer quand on ne connaît pas C/C++ ? Dans la documentation,
il n'y a même pas de tutoriels, histoire de commencer à toucher à son achat de 2490 FF... Bon allez, revenez... à cela il
faudra que vous ajoutiez en plus, de quoi apprendre le C, ce qui rendra la note encore plus amère. Déjà que le prix de base est
d'environ 169 $ pour un manuel de 200 pages (en VO). Enfin, je veux bien que le marché soit petit et qu'il faille bien survivre
mais qui est le plus vache à lait actuellement ? Le PCiste à la poursuite de la puissance ou l'amigaïste d'aujourd'hui qui veut
avoir une machine "cool" ? Avec un Visual C++ 4.0 Standard à 1150 FF TTC environ par Microsoft pour Windows, on peut se poser
réellement la question. Enfin bon, c'est la vache qui nous a racheté notre bébé, alors peut-être que nous verrons enfin se
terminer cette période d'abus... (Bruce Lepper : je ne suis pas d'accord. Microsoft va vendre, dans le monde, peut-être 500 000
Visual C, pour une somme de 500 millions de FF. ADFI va vendre combien de StormC en version française ? Je lui souhaite un
bénéfice, mais j'ai des doutes. Les gens pour qui les importantes marges bénéficiaires sont, pour une raison ou une autre,
nécessaires, sont déjà partis).
En résumé
Fort d'un environnement de développement complet C/C++, l'Amiga peut enfin se targuer de nous offrir une solution efficace pour
un développement professionnel. Cependant, StormC 2.0 souffre de quelques défauts dans son ergonomie générale comme la
non sauvegarde de la position des fenêtres des sources et le chargement automatique du/des derniers projets. Enfin, nous
attribuerons cela à la jeunesse du produit et au manque de concurrence. Les moins fortunés pourront s'orienter vers un autre
environnement de développement beaucoup moins onéreux et tout aussi dynamique dans son support, le bien-nommé ADE disponible
en version 2 dans le CD Geek Gadgets 2.
Nom : StormC 2.0.
Développeur : Haage & Partner.
Genre : développement C et C++.
Date : 1997.
Configuration minimale : Amiga OCS, 68000, 3 Mo de mémoire.
Licence : commercial.
Prix : 2490 FF.
|
|
