scanf et GTC - Page 2

Ah Je la connaissais mais en français.

Bon, je dis beaucoup de mauvaises choses sur Linux, mais n'empêche que je suis dessus actuellement, et je le trouve bien plus sympa que Windows, visuellement mais aussi au niveau des fonctionnalités

PpHd (./2) :
Parce que scanf n'est pas une fonction dy système d'exploitation et GTC ne l'a pas implanté (elle est assez grosse comme fonction et augmenterait ton programme de quelques kilos).

... parce que GTC est livré avec une version antique de TIGCCLIB (celle de TIGCC 0.94 Beta 18 du 31 mai 2002), dans laquelle mes fonctions *scanf n'avaient pas encore été intégrées. (Il n'y avait d'ailleurs qu'un proof of concept incomplet, la première version à peu près complète de mon *scanf date de septembre 2002.)

... pas la peine d'en rajouter.

Tu es lourd Kevin. (et c'est moi qui dit ça)

Je donne une explication technique détaillée de pourquoi ça n'est pas implémenté, c'est vous deux qui êtes lourds en essayant d'en faire une flamewar.

Ce qui est lourd, c'est que le posteur originel a posté une question et vous vous êtes tous mis à vous chamailler sur glibc et Cie, tant et si bien qu'il a du partir se réfugier sur développez.com...

Alors comment il fait, le ProgVal? Il change de compilo TI ? #pubtict# Il repique du code quelque part ? Il n'utilise pas scanf() ?

Il avait fermé le topic après la première réponse, donc il ne devait pas chercher une réponse très développée...

AMHA, les seules réponses dans le sujet sont ./2 et ./32. (Oui, ce message est aussi hors-sujet, désolé. )

Pour répondre à sa question de developpez.com, la solution est de prendre les sources de tigcclib dernière version et de copier (toutes) les sources nécessaires de scanf dans son programme.

Ça ne va pas marcher, c'est de l'assembleur GNU, et avec un passage par registres avec les registres spécifiés explicitement.

Je pense alors que la meilleure solution est alors de ne pas utiliser scanf.

Ximoon -> OK, je ne savais pas qu'il avait clos (et je ne sais même pas si j'avais moyen de le savoir, en fait).

PpHd, Kevin: Merci.

Link> Oh non, sauf à avoir testé entre la fermeture et la réouverture, tu ne pouvais pas savoir

sinon pour scanf, on peut utiliser gets() mais il faut faire attention à ne pas dépasser le buffer, le mieux reste de créer sa propre fonction adaptée à ses besoins ^^

Je pense alors que la meilleure solution est alors de ne pas utiliser scanf.

Vu que l'OS (AMS comme PedroM, il semble) ne propose pas cette fonction, je pense que la meilleure solution est de ne jamais utiliser scanf...

Même si Kevin a réussi à faire une implémentation bien optimisée taille (pour une fois, c'est pas une critique !), je sais pas si sur les TI-68k, il y a beaucoup de monde qui a besoin de toute la puissance de la fonction générique qu'est scanf. En effet:
* pour les entiers, on a atoi, strtol, strtoul et aussi éventuellement le builtin TIOS_strtol;
* pour les flottants, on a strtod. Actuellement, TIGCC ne contient pas la doc de la fonction et TIGCCLIB ne contient pas le wrapper nécessaire pour contourner un bug de certaines versions d'AMS (et éventuellement étendre la plage des OS supportés, puisque de mémoire, contrairement à TIOS_strtol, strtod existe aussi sous AMS 1.xx), mais strtod existe sous AMS.

A partir de ça, sauf besoins très spéciaux de parsing, c'est assez probable qu'on puisse se faire une fonction spécifique, qui sera plus petite que scanf.

Perso, même sur PC, j'utilise jamais scanf.

idem. j'en ai jamais eu l'occasion en fait, je fais toujours avec fgets+parsing "a la main"

Moi, je l'utilise dans un de mes plugins XChat pour "parser" des flux RSS (de manière totalement non conforme aux standards XML et RSS mais suffisante pour ce dont j'ai besoin).

Et les expressions régulières sur TI c'est pour quand alors ? ^^

on attend que tu fasses le portage en fait ^^

chaque fois que je code un truc, je me refais un getline

Martial Demolins (./52) :
De toute façon, il n'y a pas un seul OS sur TI qui permette de lire correctement une saisie au clavier (je parle pas de ngetchx et cie qui laisse tout le boulot à l'utilisateur, mais d'une véritable lecture du type ligne de commande).

Le monsieur m'a demandé de manière détournée d'améliorer fgets.