GTC : un TIGCC sur votre calculatrice ? - Page 23

Kevin Kofler
a écrit : Les makefiles sont le standard de facto sous *nix.

Thibaut a écrit :
> Même pas si quelqu'un les implémente pour toi ?

Ne touche pas à GTC, j'ai pas envie qu'il devienne 10 fois plus lent

Kevin Kofler
a écrit : Pourrais-tu détailler?

Oui et oui.

Si, il y a une ambigüité...

... et cela est la résolution de l'ambigüité.

Le fait est qu'en décrivant ton extension, tu n'as pas décrit la résolution de cette ambigüité est une omission, donc une erreur de documentation.

Ta résolution n'est pas la seule possible. Une autre résolution possible serait que #include en début de ligne est toujours la directive du préprocesseur et qu'il faut mettre des parenthèses ou renommer le paramètre pour utiliser la stringification. Mais les 2 résolutions sont possibles et tu en as choisi une, jusque là pas de problème. Le problème, c'est que tu n'as visiblement pas documenté ce choix.

Pollux a écrit :
Bon ben c facile : tu rajoutes un token TOKEN_MACRO_NEWLINE.
Si à la lecture tu tombes dessus, tu coupes la ligne ici, et tu mets le reste des tokens dans un buffer. Lorsqu'on voudra remplir le buffer de ligne la prochaine fois (i.e. quand on aura fini la ligne), tu mettras le reste des tokens à la place (plutôt que de lire une ligne du fichier réel et de la convertir en tokens). Pour ce qui est de la partie #macro, il suffit, lorsque tu tombes sur un '\n' dans une macro, de faire un TOKEN_MACRO_NEWLINE.

Non. C clairement conforme au standard ANSI. Si tu fais une macro #define mymac(var,unsigned) ({ unsigned int __v=var; if (unsigned) process_unsigned(__v); else process_signed(__v); }), tu auras exactement le même problème. Ca permet d'ailleurs de rajouter des nouveaux #xxx sans avoir de problème de compatibilité (de même que la gestion ANSI permet de rajouter __attribute__ sans que #define mymac(__var__,__attribute__) n'ait de problème - à condition bien sûr de ne pas utiliser __attribute__)
C'est plus une précision que #macro suit les mêmes règles ANSI que #define. Mais tu as raison, je pourrais le rajouter.

The # which begins a directive cannot come from a macro expansion. Also, the directive name is not macro expanded. Thus, if foo is defined as a macro expanding to define, that does not make #foo a valid preprocessing directive.

Non, ça ne suit pas les mêmes règles ANSI. Si tu fais:
#define if(xyz) ((void)(0)
if (0) exit(1);
alors exit(1) sera exécuté. Mais si tu fais:
#define define include
#define "xyz.h" ça ne marchera pas! Les directives du préprocesseur sont spéciales.

Pollux a écrit :
J'ai passé toute la journée à corriger les bugs de GTC on-calc Encore désolé, mais je ne crois pas pouvoir sortir GTC ce week-end, mais j'espère pouvoir le sortir un week-end après les vacances.

Pollux a écrit :
J'ai passé toute la journée à corriger les bugs de GTC on-calc Encore désolé, mais je ne crois pas pouvoir sortir GTC ce week-end, mais j'espère pouvoir le sortir un week-end après les vacances.

BiHi a écrit :
mwé bof
En tout cas je suis déçu par toi [Pollux]...
Au lieu de débattre stérilement avec Kevin (pléonasme Kevin et débat stérile dans la même phrase) et de passer ton temps sur le forum t'aurais pu travailler un peu... :]
Enfin bon j'espère que la semaine prochaine ça sera la bonne...

BiHi
a écrit : Au lieu de débattre stérilement avec Kevin (pléonasme Kevin et débat stérile dans la même phrase)

Thibaut a écrit :
> pléonasme Kevin et débat stérile
A ce propos, juste comme ça, vous connaissez le dicton "il n'y a que les imbéciles qui ne changent jamais d'avis"

XDanger a écrit :
> citer GTC dans la documentation de TIGCC, par exemple dans la FAQ, à une question du genre : "Is it possible to programming in C on calculators ?" Je ne suis pas spécialement contre, mais il faut d'abord que GTC soit releasé, et connu.

Plus de coopération de Pollux avec la TIGCC Team est indispensable

Vertyos a écrit :
À chaque fois que je voie ce topic je suis mort de rire
Entre les débats ridicules TIGCC / GTC et tout le monde qui attend "le compileur miracle" depuis des mois sans s'appercevoir que ça fait 30 fois qu'on leur répete la même chose, y'a de quoi faire

GTC il sortira quand il sortira, ou même il ne sortira pas du tout, peu importe. Le seul truc qui calmerait déjà une moitié des posteurs de ce topic serait d'annoncer une vraie date de sortie pour GTC, plutot que de le retarder d'une semaine toutes les semaines

XDanger
a écrit : Il vaut mieux que GTC sorte plus tard et (presque) bug-free, plutôt qu'il sorte trop tôt et qu'il ne soit vraiment pas fini...

Kevin Kofler
a écrit : Et sans s'apercevoir aussi que le compilateur en question ne sera pas aussi "miracle" que le prétendent Pollux et Thibaut.

Kevin Kofler
a écrit (à propos de ma suggestion de date de sortie fixée pour GTC) : Il ne faut pas rêver...

Thibaut a écrit :
> Sebastian et Zeljko le feront peut-être si GTC devient vraiment connu.
Pourquoi doit-il être connu pour mériter une place dans votre FAQ ?

Et puis, s'il est très connu, à quoi ça sert de le citer ?

Là, tu nous montres parfaitement que GTC te dérange !

> Moi, je m'y opposerai. Notre FAQ n'est pas un panneau publicitaire pour nos projets concurrents.
Ce n'est pas un concurrent, c'est un complément !

> Il refuse de coopérer depuis le début en créant des incompatibilités volontaires (dans les 2 sens).
Là aussi, tu nous montres parfaitement que GTC te dérange !

Les quelques fonctionnalités ajoutées à GTC ont pour but d'améliorer le confort de programmation sur calculatrice.

Il n'y a pas du tout une volonté de ne pas coopérer là-dedans ! La volonté était d'apporter un confort aux programmeurs on-calc.

Ceux qui veulent compiler la version finale de leur programme avec TIGCC ne les utiliseront pas.

On a dit qu'il est très performant pour un compilateur on-calc et qu'il satisfaira énormément de monde car il supporte presque le même langage que TIGCC.