Passage à VBCC
-
Pour éclairer les personnes se demandant pourquoi « la libauto c’est pour les boeufs », voici ce que j’ai à dire sur le sujet :
– l’ouverture automatique des libs ignore par défaut le numéro de version des libs. Ça veut dire que si votre programme nécessite intuition.library v40 et que seule la v36 est présente sur le système de l’utilisateur, alors le programme se lancera quand même et plantera. Pas bien.
Pour éviter cela, il existe un système simple permettant de signaler à la lib auto la version minimum de chaque lib à ouvrir, via des variables globales (voir la doc de VBCC).
– en cas de lib impossible à ouvrir, il me semble que le programme quittera sans message d’erreur, laissant l’utilisateur dans le vague. Il vaut donc mieux, dans l’idéal, ouvrir les libs soi-même et afficher un joli message d’erreur indiquant les libs manquantes (et pourquoi pas où se les procurer).
A part ça, c’est top.
Je ne sais pas pour VBCC, mais la libauto de MorphOS affiche toujours un court message (dans la console je crois, je sais plus) pour dire que telle lib n’a pas pu être ouverte.
Sinon, je trouve que ça reste pour les boeufs et que c’est la première étape vers la programmation pour les pignoufs où on ne fait jamais free() parce que c’est fait en quittant, où on alloue des gros trucs sur la pile pour pas avoir à tester un malloc, etc.
Meeeuh.
Apparement, on ne peut pas forcer une version particulière pour une bibliothèque spécifique. Cela se fait de manière globale pour toutes les libs ouvertes automatiquement.
Pas moyen non plus de forcer une révision particulière non plus. Bref, c’est vraiment nul et parfait pour faire des bugs.
Les gens qui n’ont pas envie que leur programme plante aléatoirement sur certaines configurations et pas sur d’autres.
Les gens qui n’ont ensuite pas à dire: « Ca plante ? Mais as tu lu le readme disant qu’il fallait au minimum la v11 de bidule.library et la v23 de machin.device ? » puisque de toute façon leur programme a notifié l’utilisateur au démarrage et a refusé de se lancer.
Les gens qui lisent les autodocs et remarquent les « (vNUMERO_DE_VERSION) » minimum à côté des descriptions des fonctions.
Dans le prochain épisode, nous expliquerons comment vérifier le numéro de révision d’une bibliothèque système. Mais attention, il faut d’abord apprendre à maîtriser les pointeurs et les structures de données. Et oui, programmer n’est pas une tâche triviale.
Je me disais bien que mon post allait provoquer des réactions, et à raison ! Je ne fais juste que retranscrire ce qui doit se passer chez la plupart des programmeurs. Je sais bien sûr que les numéros de version sont indiqués dans les autodocs pour chaque fonction. C’est juste qu’il est contraignant quand on programme, de vérifier la version de chaque nouvelle fonction utilisée et de faire la modif si celui-ci est supérieur au numéro de version indiquée lors de l’ouverture. Bien entendu, c’est mal.
Tiré de la doc de VBCC :
If you need at least a certain version you can define and set a variable _
Ver with external linkage, e.g. (on file-scope): int _IntuitionBaseVer = 39;
Note that your program will abort before reaching main() if one of the libraries cannot be opened.
C’est intéressant mais ce n’est apparement standardisé parmis les compilateurs Amiga/MorphOS. Et ça ne vérifie pas la révision
Oui.
__asm() pour GCC et autre chose pour VBCC.
Pour les assembleurs, il y a GAS (GNU/GCC), PASM (Frank Wille/VBCC) et peut-être d’autres (Barfly n’a pas un assembleur PPC?).
Je me vois donc obliger de poser inévitablement la même question fatiguante suite à une telle réponse : « bah pourquoi ? »
Je comprends que c’est fatiguant également d’enseigner à des incultes mais quand je pose une question c’est pour apprendre des choses dans la réponse attendue.
Merci !
- Vous devez être connecté pour répondre à ce sujet.
› Forums › AmigaOS, MorphOS et AROS › Développement › Passage à VBCC