initialisation - Page 1

est il possible de creer une fonction en C avec un paramètre prédefini à la fin:
void CenterStrX(short y, const char *str, short Attr, int underline=NULL)
{
switch(underline)
{
case 1:
DrawLine((160-DrawStrWidth(str, FontGetSys()))/2, FontGetSys()*2+6+y, (160-DrawStrWidth(str, FontGetSys()))/2+DrawStrWidth(str, FontGetSys()), FontGetSys()*2+6+y, A_NORMAL);
break;
case 2:
DrawLine((160-DrawStrWidth(str, FontGetSys()))/2-1, FontGetSys()*2+6+y, (160-DrawStrWidth(str, FontGetSys()))/2+DrawStrWidth(str, FontGetSys())+1, FontGetSys()*2+6+y, A_NORMAL);
DrawLine((160-DrawStrWidth(str, FontGetSys()))/2-1, FontGetSys()*2+7+y, (160-DrawStrWidth(str, FontGetSys()))/2+DrawStrWidth(str, FontGetSys())+1, FontGetSys()*2+7+y, A_REVERSE);
DrawLine((160-DrawStrWidth(str, FontGetSys()))/2, FontGetSys()*2+5+y, (160-DrawStrWidth(str, FontGetSys()))/2+DrawStrWidth(str, FontGetSys()), FontGetSys()*2+5+y, A_REVERSE);
DrawLine((160-DrawStrWidth(str, FontGetSys()))/2, y-1, (160-DrawStrWidth(str, FontGetSys()))/2+DrawStrWidth(str, FontGetSys()), y-1, A_REVERSE);
DrawLine((160-DrawStrWidth(str, FontGetSys()))/2-1, y-2, (160-DrawStrWidth(str, FontGetSys()))/2+DrawStrWidth(str, FontGetSys())+1, y-2, A_NORMAL);
DrawLine((160-DrawStrWidth(str, FontGetSys()))/2-1, y-2, (160-DrawStrWidth(str, FontGetSys()))/2-1, FontGetSys()*2+6+y, A_NORMAL);
DrawLine((160-DrawStrWidth(str, FontGetSys()))/2+DrawStrWidth(str, FontGetSys())+1, y-2, (160-DrawStrWidth(str, FontGetSys()))/2+DrawStrWidth(str, FontGetSys())+1, FontGetSys()*2+6+y, A_NORMAL);
break;
default:
break;
}
DrawStrXY((160-DrawStrWidth(str, FontGetSys()))/2, y, str, Attr);
}
C'est une fonction qui centre le texte en X, et qui si Underline est active souligne ou crée un cadre autour(pas encore terminée)

come
: est il possible de creer une fonction en C avec un paramètre prédefini à la fin

Non, ce n'est pas du C++.

Ah?
D'accord, C très dommage, parce que bien pratique.
Mais c'est pas grave (entre C++, C, Casio basic et TI-Basic je sais plus moi)
Merci.

Tu peux passer ta source dans LWC, mais ça oblige à ne pas inclure TIGCClib

Normal, les headers TIGCCLIB ne sont même pas approximativement de l'ISO C++ valide. (C'est du GNU C.)

Il crache une erreur à chaque asm("...");

extern int asm(char *s); devrait corriger une partie des problèmes

Pas avec les asm avec opérandes C.

C'est pour ça que je dis une partie !!!

Il a pas dû faire gaffe
Errare humanum est (ou un truc comme ça) !

J'en connais qd même certains qui pourraient faire gaffe plus souvent

Tu penses à Paul Froissart ?
T'as raison, à chaque fois qu'il m'envoie une bêta de GTC, ça plante parcequ'il a oublié un truc (copier-coller, ...)

Mouais Tu veux que je fasse des modif tellement souvent que j'ai même pas le temps de faire Ctrl-F5 pour voir si ça marche

C'est pas ma faute si Einstein fait boguer GTC toutes les 10 lignes !

On est encore loin d'arriver à le compiler !
Sans compter les lignes de commentaires et les lignes vides, la source d'Einstein fait :
+ 3568 lignes de C
+ 453 lignes d'ASM
= 4021 lignes de code

4021 / 10 = 402 bêtas avant d'arriver à le compiler entièrement

A raison de 12 bêtas par semaine (c'est le rythme qu'on a pris), je pourrais anoncer la sortie du nouvel Einstein plus petit et plus rapide à se lancer... dans 8 mois

LOL Si tu veux j'examine les mails envoyés et je regarde quelles sont les updates qui sont réellement des bugfixes, il ne doit pas y en avoir tant que ça

Y'en a un certain nombre... Un nombre certain... On va dire 6, par là

Moins que ça. Franchement la plupart étaient des additions au compilo ou à la lib.

C'est vrai.
Mais j'en connais un qui considèrerait ça comme des bugs, puisque ça bloquait la compilation ...

Oui mais c'est totalement non-standard (il y avait même une extension non supportée avant GCC 3.1)

Thibaut
: C'est pas ma faute si Einstein fait boguer GTC toutes les 10 lignes !

Et voilà... Et avec ça, tu (Pollux) prétends que ton modèle de développement et de tests fermé donne quelque chose de plus stable...

On est encore loin d'arriver à le compiler !
Sans compter les lignes de commentaires et les lignes vides, la source d'Einstein fait :
+ 3568 lignes de C
+ 453 lignes d'ASM
= 4021 lignes de code

4021 / 10 = 402 bêtas avant d'arriver à le compiler entièrement

A raison de 12 bêtas par semaine (c'est le rythme qu'on a pris), je pourrais anoncer la sortie du nouvel Einstein plus petit et plus rapide à se lancer... dans 8 mois

Bref, repasse à TIGCC et ne fais pas ch**r.

Pollux
: (il y avait même une extension non supportée avant GCC 3.1)

GCC 3.1, c'est vieux, ça!
On en est à GCC 3.3 là, donc si tu es encore en train de lutter avec la compatibilité avec GCC 3.1, tu en as du retard!

Lui il est tout seul ... y'a pas 50 developpeurs derrière

Kevin, ne recommence pas à faire des remarques énervantes, s'il te plaît !
Je ne répondrais pas à tes posts pour éviter de tomber une nouvelle fois dans un débat sans fin.

Kevin>
Ne dis pas n'importe quoi. J'ai classifié tous les "bugs" que m'a dit Thibaut, et dans les vrais bugs, il y en a un qui aurait pu potentiellement conduire à une génération de code incorrect (mais qui a donné une erreur ici), et deux autres qui donnaient une erreur pour du code C valide.

Et je parie que tu as exactement les mêmes problèmes pour les beta-tests des premières pré-version de TIGCC, donc ne fait pas le malin...

Pollux
: Et je parie que tu as exactement les mêmes problèmes pour les beta-tests des premières pré-version de TIGCC, donc ne fait pas le malin...

Là, on est loin des "premières pré-versions" et tu as toujours des tonnes de bogues dans ton compilateur.
GCC 3.3 avait beaucoup moins de problèmes. La plupart des programmes testés (dont TI-Chess) compilent depuis le premier prerelease public.

TI-Chess a compilé sans pb. Si tu veux voir le log de portage :

		** Porting log for TI-Chess **

- several object files : created a "tic.c" file for inclusion of other files
- inclusion of specific headers like <sprites.h> : #ifndef-ing out
- use of 'long long' type for hash keys :
	. modified definition of hash_t in "defines.h"
	. fixed comparison in "opening.c"
	. fixed cast to short, generation with Random32() and xoring in "hash.c"
- converted assembly statements in "generic.c", "waitms.c" and "tichess.c"

S'il y avait des tonnes de bogues, j'aurais peut-être eu plus de pb Et il n'y a eu que 3 bogues dont deux corrigés très facilement dans Einstein, donc je ne vois absolument pas ce qui te fait calomnier de la sorte sur mon compilo ("tu as toujours des tonnes de bogues dans ton compilateur" -> tu l'as testé???)

Ton compilateur ne comprend même pas long long???

Pollux : Il est mort d'inquiétude que TIGCC ait un "concurrent" sérieux, c'est pour ça qu'il a cette agressivité.
Je trouve ça lamentable, mais bon...


Kevin : bordel mais ferme ta gueule ! Tu te crois intelligent ?