bug avec tigcc 0.95 - Page 2

c'est bon, tout passe nickel maintenant

Pollux
:

.F3o

erf

Je sens que je vais devoir passer à une notation de style .F3.15 un de ces jours. Au plus tard pour .F3.27.

Bah de toutes façons tu vas plus faire d'updates majeurs en dehors de ceux que tu as fait pour 0.95?

Probablement pas, mais c'est à voir.

Meuh si, Kevin va nous pondre un compilateur C++ !

Non je déconne, le jour où il fera ça c'est qu'il sera devenu gâteux...

Fais gaffe ne lui en parle pas sinon !

Pourquoi gâteux? Il y a certainement moyen de faire un compilo C++ aussi efficace qu'un compilo C (optimisations globales sur le format des classes). Le problème, c'est que c'est bcp plus long à implémenter

Non non pas tant que ça: la programmation orienté objet ne complique pas tant
les choses, le compilateur c'était déjà LE truc énorme.

La POO repose sur des trucs cons en fait:

Par exemple, les méthodes:

class chien
{
// ...
char *nom;
int bourrin;
void aboyer(void) etc...
}

chien Médor; //
chien Choupette; //
Médor.bourrin = 100000;
Médor.aboyer(); // Ou Médor::aboyer(), ok ...

Quand Médor le gros toutou aboie il aboie plus fort que Choupette le petit chien (où est la queue où est la tête ?)

C'est simulé en fait. A la compilation de la classe, ça fait:

void aboyer(chien &lechien)
{
if (lechien.bourrin > 5000) cout << lechien.nom << " rugit comme un lion.";
else cout << lechien.nom << " aboit pitoyablement.";
}

Les méthodes sont des fonctions et le compilateur rajoute un paramètre: le passage par référence (pas par pointeur, par
référence) (mais ça revient au même de toute façon )

Ainsi, on dit:

Médor.aboyer();

Et ça fait en fait:

aboyer(&Médor);

On a l'impression comme ça que chaque "chien" peut aboyer à sa façon. Or "aboyer" est unique et ça dépend de
la propriété "bourrin" qu'il a.

Et c'est comme ça pour tout: tout se simule ou se simplifie, les héritages etc.

Et encore une fois, y'a des BOUQUINS dessus (erf!)

Excellents mes exemples hein ?

sérieusement c un clone lui c pas possible qu'il soit vraiment comme ça

Euh sinon snow-tiger y a plein de trucs à gérer en plus de rajouter le mot-clé et le type class au parser Par exemple, les templates... et il y a certainement plein d'autres choses (je ne connais pas encore trop le C++)
Enfin si tu veux le faire lâche-toi

Meuh non, au niveau du compilateur c'est pas le plus compliqué.

Sérieusement, entre faire le GCC, et faire une machine virtuelle qui traduise du C++ en C pour qu'on puisse le
compiler sous TIGCC (J'y ai pensé mais je veux pas m'em***der), je préfère largement la seconde
option. En plus, ce serait presque forcément moins bien que de prendre le g++ et l'adapter.

Au fait où on peut trouver la Beta 2 de tigcc 0.95 (celle qui foire pas) pour Win32 ?

Ben écoute si tu veux vraiment faire un convertisseur C++ -> C, amuse-toi

C'est un peu facile de dire "J'y ai pensé mais je veux pas m'em***der", parce que c certainement bcp plus long que tu ne le crois. Regarde LWC, ça ne gère qu'une petite partie du C++ et c'est déjà relativement gros.

Pollux :
Ben écoute si tu veux vraiment faire un convertisseur C++ -> C, amuse-toi

Beaucoup de langages se compilent en se traduisant en C, comme les
langages fonctionnels et les différences entre C et C++ sont ne concernent QUE la POO et c'est tout. Le C++ n'est pas comme C# ou Java il n'est pas basé sur
la POO même si c'est sa raison d'être, c'est pas quelquechose de crucial.

C'est un peu facile de dire "J'y ai pensé mais je veux pas m'em***der", parce que c certainement bcp plus long que tu ne le crois.

Pour un langage normal une compilation est un truc complexe. Mais dans le
cas C++ -> C, c'est pas si long car les deux sont proches. Comme je l'ai dit plus
haut, toutes les aspects POO du C++ peuvent se réduire à du C normal.

J'ai bien marqué l'exemple des méthodes.

Regarde LWC, ça ne gère qu'une petite partie du C++ et c'est déjà relativement gros.

Donc gros = compliqué.
Or j'ai déjà dit plus haut qu'avec les bouquins
tout le monde peut faire son compilateur tant qu'il y met du temps.

Beaucoup de langages se compilent en se traduisant en C, comme les
langages fonctionnels et les différences entre C et C++ sont ne concernent QUE la POO et c'est tout. Le C++ n'est pas comme C# ou Java il n'est pas basé sur la POO même si c'est sa raison d'être, c'est pas quelquechose de crucial.

Il y a quand même de différence entre C++ et C même en dehors de la programmation objet comme entre autre : la surcharge, la déclaration à tous les niveaux, les enum,struct,... qui font automatiquement le typedef, les enum qui ne correspondent plus directement a un numéro ...

Donc gros = compliqué.

Justement LWC est plustôt simple et il est assez gros donc imagine si ca avait été plus complexe

Pour ce qui est du compilateur/traducteur fait le si tu le veux. Ca parait parfois assez facile, mais c'est en fait toujours bien plus compliqué qu'il n'y parrait au premier abord.

Il y a quand même de différence entre C++ et C même en dehors de la programmation objet comme entre autre : la surcharge, la déclaration à tous les niveaux, les enum,struct,... qui font automatiquement le typedef, les enum qui ne correspondent plus directement a un numéro ...

Ben oui, c'est pour ça que j'ai dit que ça "m'em***rderais" de le faire.

[cite]

Donc gros = compliqué.

Justement LWC est plustôt simple et il est assez gros donc imagine si ca avait été plus complexe
[cite]

Par gros = compliqué j'étais ironique.

Donc gros = compliqué.

Or j'ai déjà dit plus haut qu'avec les bouquins tout le monde peut faire son compilateur tant qu'il y met du temps.

Je ne dis pas que ça demande des capacités monstrueuses en algorithmie, loin de là. Mais c'est très long, on est bien d'accord. D'ailleurs si tu regardes mon post tu verras que je ne parle que de longueur et de taille, c'est tout. En tout cas c'est bien moins simple que ce que tu avais l'air de vouloir sous-entendre...

Je ne dis pas que ça demande des capacités monstrueuses en algorithmie, loin de là. Mais c'est très long, on est bien d'accord. D'ailleurs si tu regardes mon post tu verras que je ne parle que de longueur et de taille, c'est tout.

Je suis d'accord

En tout cas c'est bien moins simple que ce que tu avais l'air de vouloir sous-entendre...

Ben le principe est simple et la pratique est chiante.
Mais je veux dire que y'a des trucs dont le principe est compliqué et alors la pratique, on imagine...

Je veux dire qu'il y a bien pire.

Bah, tout dépend des contraintes que tu t'imposes. Si tu veux que ton prog traite 10 ko/s sur TI et qu'il prenne moins de 15 ko, alors c vraiment ultra-chaud

Cela dit si tu le programmes "à la programmeur pour PC" il n'y a aucune difficulté, effectivement.

Pollux :
Bah, tout dépend des contraintes que tu t'imposes. Si tu veux que ton prog traite 10 ko/s sur TI et qu'il prenne moins de 15 ko, alors c vraiment ultra-chaud

Cela dit si tu le programmes "à la programmeur pour PC" il n'y a aucune difficulté, effectivement.

Que veut dire "à la programmeur pour PC" ?
J'ai pas dit que je ferais un truc comme ça on-calc,
et dans ce cas-là ça serait long de toute manière, alors entre long
et très long... (Sous-entendu: j'en ai plus rien à foutre

"A la programmeur PC", c'est pour dire de façon déguisée qu'il optimise comme un dieu (quelle modestie...).

Il doit vouloir dire "que dalle optimisé".

Mais c'est compréhensible, vu la terrible puissance qu ça a.

L'autre fois, j'ai remarqué qu'il fallait peut-être 1000 ou 10 000 fois plus d'instructions NOP
à mon Athlon Thunderbird 900 que pour la caltos pour attendre autant.


J'ai pas encore testé la Beta 2 de TIGCC 0.95.

snow-tiger :
L'autre fois, j'ai remarqué qu'il fallait peut-être 1000 ou 10 000 fois plus d'instructions NOP
à mon Athlon Thunderbird 900 que pour la caltos pour attendre autant.

Vraiment lamentable... Y'a pas besoin de faire des tests pour savoir ça

Désolé mais en théorie, un 68000 équivalent à peut-être la moitié d'un Pentium 60, disons qu'il vaut
30 (unités arbitraires)
Et mon Athlon étant à 900 Mhz, disons qu'il en vaut 1000 (900 Mhz + améliorations techniques, plus de puissance à fréquence égale)

C'est totalement arbitraire ,
mais la théorie ne suffit ici pas à justifier un écart de 1 000 000 % ( espèce de... de Pavel ! )

C'est un peu portnawak ce que tu dis... Un 68k est plus proche (en terme d'architecture, même si on est dans deux mondes opposés [68k/x86]) d'un 386/486 (structure 8/16 bits) que d'un pentium.

Ben je connais un vieil électronicien ( la cinquantaine) qui dit qu'à fréquence égale,
des instructions du Pentium se font 4 fois plus lentement que sur 68k.

Pas sur tout, hein, et en pratique j'ai vu qu'un 68060 à 25 Mhz arrive qu'au niveau d'un
Pentium 66

Bah en pratique, ça n'a rien à voir... Les jeux d'instructions ne sont pas les mêmes, l'architecture en elle même a tout qui les oppose. C'est comme comparer une fusée russe et une fusée américaine... yen a pas de meilleure : l'une est plus "agréable" à utiliser, l'autre n'a pas d'égal en matière de lancements... Il est donc inutile de vouloir comparer ce qui n'est pas comparable.

Bah en pratique, ça n'a rien à voir... Les jeux d'instructions ne sont pas les mêmes, l'architecture en elle même a tout qui les oppose. C'est comme comparer une fusée russe et une fusée américaine... yen a pas de meilleure : l'une est plus "agréable" à utiliser, l'autre n'a pas d'égal en matière de lancements...

Bien d'accord !

Il est donc inutile de vouloir comparer ce qui n'est pas comparable.

Bah je montre juste ce qui étonne dans ce domaine-là.

AU FAIT, y'a des routines d'attentes sous TIGCC ?