Développement FinCalc - Page 1

Bonsoir,

Je développe actuellement un calculateur financier pour le platforme Atari (ST, TT, Falcon).
Etant novice dans le développement GEM et n'ayant que peu d'expérience en C, je me permet d'ouvir ce fil afin d'y poser diverses questions pour me permettre d'avancer dans le développement. D'avance merci pour votre aide.
Précision: je développe sous Lattice C 5.6 sur un Falcon 030 et sur MacAranym. Je dispose des trois manuels de Lattice C, ainsi que l'ouvrage "Programmation GEM" de micro application.

Voici donc ma première question:
Comment puis-je convertir un "double" en un string (un pointeur de char). Il existe des routine pour convertir des entiers vers des string (stci_d, et al), mais je ne trouve pas l'équivelant pour le double...

Merci

François

Pour le Gem il y a quelques personnes qui pourront t'aider ici (Rajah, moi meme ) par contre pour le C, GT plus la



GT

Regarde la description de la fonction "sprintf()".
Un simple sprintf(chaine, "%f", nombre); devrait suffire (attention à bien prévoir un buffer assez grand pour accueillir la chaîne).

Bonjour à tous,

Afin d'accélérer le développement de FinCalc, j'ai décidé de mettre à disposition le code source. Ainsi, lorsque j'ai des questions/problèmes, il sera plus aisé pour ceux désireux de m'aider de comprendre les raisons du problème.
En attendant de faire un joli site, vous trouverez le code source de la version 0.0.1 ici

Petite précision au sujet de l'environnement de développement que j'utilise:
- Lattice C 5.6
- Interface 2.33
- Falcon 030 avec FPU 68882
- TOS (pas de MINT/XAEES)

Lattice C 5.6 est disponible sur le net. J'avais il y a quelques mois envoyé un mail à HiSoft pour savoir si il leur restait des copies de Lattice C. Ils m'on répondu que non et qu'il fallait donc le trouver sur internet.... Donc, j'en déduis qu'il s'agit d'un abandonware...

Premier problème à résoudre:
La fenêtre des résultats affiche des caractères bizarres à chaque début de ligne. Probablement un soucis avec les pointeurs que j'utilisent sur le "buffer" de sortie... Le code incriminé est je pense les fonctions AppendXXXX du fichier utils.c, mais je n'arrive pas à identifier le problème.

Pour plus de facilité, je suggère de communiquer par mail, en utilisant "[FINCALC]" en début de sujet du mail.

D'avance merci

François

brainois (./4) :
En attendant de faire un joli site, vous trouverez le code source de la version 0.0.1 ici

J'ai essayé le lien, mais il n'y a rien au bout.

JFL

Bonjour jfl,

Le lien amène à un page où on peut télécharger le code. Je viens d'essayer et cela marche. Mais il est vrai qu'au tout début, j'avais mis un lien direct er que cela ne fonctionnait pas...

François

Bonjour,

brainois (./6) :
Le lien amène à un page où on peut télécharger le code. Je viens d'essayer et cela marche. Mais il est vrai qu'au tout début, j'avais mis un lien direct er que cela ne fonctionnait pas...

OK. Je viens de réessayer avec Firefox, et c'est bon. C'est Konqueror qui déconne. C'est fou, ça.

JFL

brainois (./4) :
La fenêtre des résultats affiche des caractères bizarres à chaque début de ligne. Probablement un soucis avec les pointeurs que j'utilisent sur le "buffer" de sortie...

Salut,
Je n'ai pas pu vérifier ton problème parce que l'exécutable n'est pas inclus, mais après un rapide coup d'oeil aux sources je vois que tes "char *str" ne sont pas initialisés (où strcat écrit-t'il ?).

JFL

jfl (./8) :

brainois (./4) :
La fenêtre des résultats affiche des caractères bizarres à chaque début de ligne. Probablement un soucis avec les pointeurs que j'utilisent sur le "buffer" de sortie...

Salut,
Je n'ai pas pu vérifier ton problème parce que l'exécutable n'est pas inclus, mais après un rapide coup d'oeil aux sources je vois que tes "char *str" ne sont pas initialisés (où strcat écrit-t'il ?).

JFL

Question en C quand c'est pas initialisés cela n'est pas 'init' par défaut a 0 ?

GT Trop nul en C

Pour schématiser :

Question en C quand c'est pas initialisés cela n'est pas 'init' par défaut a 0 ?

Un pointeur, c'est juste une variable qui pointe sur une adresse en mémoire.
Donc, à l'initialisation (mettons via une allocation mémoire, ou la déclaration d'un tableau), la valeur du pointeur est correcte, mais le bloc mémoire réservé, lui, n'est pas forcément remis à 0.
Je pense que c'est la même chose en assembleur, non ?

Exemple typique sur Lynx :
Tu fais un jeu qui marche sous émulateur
Tu le télécharges sur la Lynx via BLL et là, il ne marche pas pareil
-> si tu n'initialises pas tes variables et zones mémoires utilisées, sur Lynx, vu qu'un autre programme était en mémoire avant (le loader BLL), ta mémoire vive contient déjà des données (contrairement à Handy ou elle est vide vu que tu démarres la console avec ton jeu). Du coup, si tu n'initialises pas toi-même, tu as des surprises.

Ce n'est pas vraiment lié au C, je suis à peu prêt sur qu'en asm, ça fait la même chose, et même en GFA quand tu fais un MALLOC (le contenu de la zone réservée ne doit pas être nickel)

GT Turbo (./9) :
Question en C quand c'est pas initialisés cela n'est pas 'init' par défaut a 0 ?

Salut,
Oui pour les variables externes et statiques. La valeur des automatiques est indéterminée, ce qui est le cas ici. Mais si "ptr" n'est pas un espace mémoire alloué par un appel à malloc() ou par le compilateur, "strcat(ptr, "texte")" écrit n'importe où -- à moins que je ne comprenne encore moins bien le C que je ne le crois.

JFL

Fadest (./10) :
Pour schématiser :

Question en C quand c'est pas initialisés cela n'est pas 'init' par défaut a 0 ?

Un pointeur, c'est juste une variable qui pointe sur une adresse en mémoire.
Donc, à l'initialisation (mettons via une allocation mémoire, ou la déclaration d'un tableau), la valeur du pointeur est correcte, mais le bloc mémoire réservé, lui, n'est pas forcément remis à 0.
Je pense que c'est la même chose en assembleur, non ?

Exemple typique sur Lynx :
Tu fais un jeu qui marche sous émulateur
Tu le télécharges sur la Lynx via BLL et là, il ne marche pas pareil
-> si tu n'initialises pas tes variables et zones mémoires utilisées, sur Lynx, vu qu'un autre programme était en mémoire avant (le loader BLL), ta mémoire vive contient déjà des données (contrairement à Handy ou elle est vide vu que tu démarres la console avec ton jeu). Du coup, si tu n'initialises pas toi-même, tu as des surprises.

Ce n'est pas vraiment lié au C, je suis à peu prêt sur qu'en asm, ça fait la même chose, et même en GFA quand tu fais un MALLOC (le contenu de la zone réservée ne doit pas être nickel)

Pour l'asm, théoriquement un pointeur comme celui la, initialisé par le programme est en BSS, zone qui est 'censé' etre nettoyé lors du lancement du programme par l'O.S. (J'ai écrit censé car cela peut etre faux en cas d'utilisation de compacteur, un prog compacté en auto decompactable n'a souvent pas cette section nettoyé, mais bon nous sommes pas dans ce cas).

J'ai un peu mal compris car mon niveau en C est bas et meme en regression. Car dès que je vois un char, pour moi c'est un octet (Caractère) et le str me faisait penser a une 'string' donc chaine de caractere et pas a un pointeur.

Mais on va emettre des suppositions :

- ton pointeur pointe sur 0, donc debut de la 'ram interne du 68000 (on va dire)', donc a chaque lancement tu devrais avoir les memes caractères. Et si tu ecris a cette adresse, ton prog doit bien planter.

- ta chaine n'est pas fini ou initialisé avec un zero (null byte), donc tu devrais avoir des chaines affichés avec des longueurs et des caractères différents.

car l'affichage de texte sou VDI, la chaine doit se finir par un 0, tant que j'y penses tu utilises V-Text pour l'affichage ?

GT

ton code est beau

GT Turbo (./12) :
J'ai un peu mal compris car mon niveau en C est bas et meme en regression. Car dès que je vois un char, pour moi c'est un octet (Caractère) et le str me faisait penser a une 'string' donc chaine de caractere et pas a un pointeur.

"char *str" déclare un pointeur sur char, pas une chaîne de caractères. Si "str" est une chaîne (c.-à-d. un tableau de chars, par exemple défini avec "char str[32]"), dans ce cas "*str" == str[0].

JFL

jfl (./14) :
"char *str" déclare un pointeur sur char, pas une chaîne de caractères. Si "str" est une chaîne (c.-à-d. un tableau de chars, par exemple défini avec "char str[32]"), dans ce cas "*str" == str[0].

Problème de balises, apparemment, alors j'ajoute des " autour de [ qui n'ont rien à faire là :
*str == str"["0].
JFL

GT Turbo (./9) :
Question en C quand c'est pas initialisés cela n'est pas 'init' par défaut a 0 ?

En fait depuis les Tos 3.x, dans les flags d'un programme, on peut préciser si la mémoire doit être initialisée à zéro ou non. Ca a été rajouté parce que autant sur ST, mettre à zéro 512Ko ou 1Mo, ca va, autant sur un TT ou Falcon (avec plusieurs Mo de RAM, sans compter la FastRam) ca pouvait mettre plusieurs secondes à chaque fois que tu lançais un programme.

Donc c'est simple, il vaut mieux considérer que la mémoire n'est jamais initialisée à zéro, et le faire soi-même. Lire une valeur en mémoire à une adresse où rien n'a été écrite avant par le programme doit être considéré comme un bug.

En C, tu peux utiliser calloc() au lieu de malloc(), qui va effectivement mettre à zéro la mémoire après l'avoir allouée.

Oulala, cela fait un bail que je ne suis plus passé par ici... J'ai quelques soucis avec le falcon que j'ai acheté (lecteur disquette qui fait des siennes). Merci pour toutes les interventions... Je vais dès que possible reprendre la programmation de FinCalc...

François

Bonsoir,

Et bien voilà, ce WE je me suis remis à la programmation sur mon Falcon...

Voici donc une nouvelle version (toujours sous Lattice C 5.6) qui n'apporte aucune fonctionnalité nouvelle... En effet, je me suis attelé ce WE à coder un outil de logging qui permet, via un fichier de configuration, d'activer différents niveaux de logging (un peu comme le fait log4c).

Rien d'extraordinaire pour des programmeurs C aguéris, mais pour moi qui ne suis qu'un débutant, ce fut intéressant... et surtout, cela permettra de faciliter le traçage et le deboggage de FinCalc.

La version du 22/07/2007 se trouve ici.

PS: toujours les même bugs, je n'ai pas encore eu le temps d'investiguer moi-même...

François