Où est CC ? - Page 9

Les sources de SMA sont dispo.... Ainsi que celles de Fer3 et CF
Et puis même s'ils n'étaient pas dispo, ce n'est pas une raison pour faire pareil...

> C'est le batch de Thibaut qui est en français.
Pour être franc, je m'en étais douté un peu (je me fous que tu me croies ou pas, je le dis et c'est tout)... Mais ça n'était pas spécialement évident, vu que le batch s'appele "gtc"...
Je me disais que tu n'étais pas stupide, quand même...

> Je ne vois rien de volontairement incompatible. La seule incompatibilité avec TIGCC est la syntaxe asm, mais ça c'est dû à une différence de fonctionnement interne et je n'y peux rien, à moins de rajouter 20 ko au compilo, ce dont je n'ai aucune envie.
Tu ne voulais pas rajouter un #macro ou quelque chose dans le genre ? Il me semble que tu avais posté ça une fois, que Kevin t'avait dit que c'était une mauvaise idée et avait donné des arguments pour expliquer pourquoi il pensait que c'était une mauvaise idée...
Je n'ai pas le temps de retrouver les posts (je vais à nouveau arrêter, et définitivement pour ce soir), mais je sais ce que je cherche et je sais à peu près les deux ou trois topics où je peux le trouver. Ca ne devrait pas être extrêmement difficile...

Pollux a écrit :
Non, le compilateur dont tu parles (et dont dérive CC) dérive de C68k par Matthew Brandt, comme Ontic et GTC. Manquerait plus que GTC doive obéir à la license de CC parce qu'il dérive lui aussi de C68k

Et d'ailleurs si je voulais chipoter (comme qui, je ne sais pas ) je dirais que CC est totalement illégal puisqu'il n'inclut pas la notice de Matthew Brandt qui demande expressément dans sa licence que "this notice stays intact", licence qui n'est pas incluse dans CC

Ben voyons
Comme je l'ai déjà dit, CC est une adaptation de CC68III3, et celui-ci impose de releaser les sources, avec la license qu'a donné Kevin au début de chaque fichier source, et absolument rien d'autre dans la doc. Et il suffit de downloader CC pour se rendre compte que je n'ai rien enlevé, que les notices sont toutes toujours la, et que je respecte donc la license.

Ensuite, je ne crois pas que le fait de releaser les sources de GTC ait la moindre utilité : qui est allé corriger les bugs de CC

Si tu n'avais pas annoncé GTC a n reprise pour les prochaines vacances, je me serais penché dessus.

En plus, je m'engage à corriger tous les bugs que vous trouvez (qd GTC sera sorti bien sûr ), donc je ne vois vraiment pas de quoi vous vous plaignez

je me plaint pas mais si un jour tu quitte la communauté ca serait dommage que GTC ne puisse plus être mis a jour

lol vu les giga-octets à télécharger avant de pouvoir compiler TIGCC, on peut pas vraiment dire qu'il soit libre

t'abuse la s'il était pas vraiment libre TIGCC n'aurait jamais vu le jour.

Très sincèrement, je ne vois pas quelle fonction on pourrait avoir envie de rajouter à GTC, qui ne soit ni trop lente ni trop gourmande en mémoire (à part les opérandes passées aux asm(), mais ça arrive)

Le porter sous linux est un des idées qui me vient, ou une nouvelle fonctionalité du kernel qui nécessite une modification du linkeur...

1) Je ne vois rien de volontairement incompatible. La seule incompatibilité avec TIGCC est la syntaxe asm, mais ça c'est dû à une différence de fonctionnement interne et je n'y peux rien, à moins de rajouter 20 ko au compilo, ce dont je n'ai aucune envie.
2) "implémentation partielle du GNU C" : à part, encore une fois, les opérandes pour l'ASM inline qui va arriver, il n'y a rien, à ma connaissance, qui soit assez utile pour valoir les ko de compilo, les dizaines de ko de RAM et les secondes de compilation supplémentaires qu'il faudrait pour qu'elle marche 3) closed-source : cf post précédent, il n'y a vraiment aucune utilité.

1) et 2) d'accord a 200%
3) cf plus haut, c'est dommage mais ca ne justifie pas l'attitude de Kevin et Xdanger

> Pour être franc, je m'en étais douté un peu
Excuse-moi, mais faire une critique aussi virulente ["On dirait que GTC n'a pas encore assez de défauts et qu'il faut donc en rajouter"] alors que tu te doutais que ce que tu disais était complètement faux, ça révèle vraiment la mauvaise foi de certains de tes posts...

> Tu ne voulais pas rajouter un #macro ou quelque chose dans le genre ?
Si, mais je ne sais pas encore si je vais l'inclure tel quel ou pas : étant donné que le préprocesseur C et le préprocesseur ASM sont les mêmes (encore une fois, je le répète, par souci de place, et en plus il se trouve que c'est bien plus pratique parce que les #define's sont en commun), et que #macro est presque indispensable pour l'ASM, je vais peut-être déconseiller fortement l'utilisation de #macro en C, pour permettre la compatibilité avec TIGCC. D'ailleurs, encore un avantage de ne pas avoir sorti de pré-version de GTC : je peux modifier les extensions comme je veux, sans créer d'incompatibilités dans les sources (par exemple, j'ai déjà changé la syntaxe qui était "asm { ... }" en "asm { ... };", alors que si GTC était sorti avant, soit toutes les sources auraient été rendues incompatibles, soit je n'aurais pas pu rendre la syntaxe plus logique).

> Je n'ai pas le temps de retrouver les posts
Franchement il y a des fois où je ne te comprends pas... Pourquoi est-ce que tu tiens à retrouver ces posts? Tu crois que je vais nier avoir ajouté #macro???
C'est hallucinant cette absence de confiance

> Si tu n'avais pas annoncé GTC a n reprise pour les prochaines vacances, je me serais penché dessus.
Désolé

> je me plaint pas mais si un jour tu quitte la communauté ca serait dommage que GTC ne puisse plus être mis a jour
Si je quitte (ou plutôt quand je quitterai) la communauté je releaserai évidemment les sources (à moins bien sûr que je meurs soudainement avant ). Ce serait vraiment idiot de ma part de vouloir garder les sources alors que je ne m'en occupe plus.

> t'abuse la s'il était pas vraiment libre TIGCC n'aurait jamais vu le jour.
Oui, GCC est libre, et il a permis à TIGCC de voir le jour (je ne critique pas l'open-source, bien au contraire). Mais on peut pas dire de TIGCC qu'il est vraiment libre.

> Le porter sous linux est un des idées qui me vient, ou une nouvelle fonctionalité du kernel qui nécessite une modification du linkeur...
C vrai que c un peu dommage pour linux, même si ça ne reste pas une priorité... Est-ce que c possible de publier des binaires pour une plate-forme donnée (x86 par exemple), indépendamment de la config précise (version de Linux, etc...), ou est-ce que les sources sont indispensables?
En ce qui concerne les nouvelles fonctionnalités du kernel, je me ferai une joie de les porter s'il y en a des nouvelles.

nitro> alors C68III3 doit être aussi "illégal", s'il n'y a pas la notice de Matthew Brandt. Enfin bon perso je m'en fous. C pas franchement grave (enfin sauf peut-être pour Kevin )

Si je quitte (ou plutôt quand je quitterai) la communauté je releaserai évidemment les sources (à moins bien sûr que je meurs soudainement avant ). Ce serait vraiment idiot de ma part de vouloir garder les sources alors que je ne m'en occupe plus.

met sur rton site un compte a rebours qui release la source tout les 3 mois si tu le retarde pas comme ca tu peut mourrir tranquillement

> Franchement il y a des fois où je ne te comprends pas... Pourquoi est-ce que tu tiens à retrouver ces posts? Tu crois que je vais nier avoir ajouté #macro???
Non. Mais tu sais très bien que je recherche souvent ce qui a été écrit. Pas plus tard qu'hier soir, je l'ai fait à propos de la phrase de Ximoon

> C'est hallucinant cette absence de confiance
Il y a des personnes ici à qui je ne fais pas spécialement confiance (à divers degrés), et tu en fais partie ("Mister vaporware").

> Mais on peut pas dire de TIGCC qu'il est vraiment libre.
Arguments ? Visiblement, ça ne suffit donc pas, l'open-source et la possibilité d'ajouter des trucs à TIGCCLIB ?
Je parie qu'on va encore entendre parler du comportement de la TIGCC Team et gnagnagna (pas forcément de la part de Pollux, mais de la part de Thibaut ou de personnes du même genre)...

Gagné ! et si on est pas mal à le penser, il faudrait peut-être que vous vous demandiez si vous n'êtes pas effectivement un petit peu en tort

Je confirme que GTC est évidemment en anglais. J'ai quand même le droit de faire MES batchs personnels à moi qui m'appartiennent pour moi dans la langue que je veux

XDanger
a écrit : ce qui est le plus du n'importe quoi dans ton post, le post que j'ai critiqué, c'est de proposer de bannir Kevin...

Visiblement, t'as pas vu que je ne disais pas ça sincèrement. Retourne voir, t'as pas vu le smiley "".
Pour le reste, tu es donc plus ou moins d'accord que Kevin exagère à vouloir présenter GTC au même niveau que CC (== le déconseiller pour toute autre chose qu'un Hello World) ?

Est-ce que c possible de publier des binaires pour une plate-forme donnée (x86 par exemple), indépendamment de la config précise (version de Linux, etc...), ou est-ce que les sources sont indispensables?

Bah on peut toujours essayer d'adapter les binaires d'une plateforme a l'autre(il me semble que c'est ce que fait wine) mais je souhaite bon courage a celui qui tente ca car je n'ai aucune idée de comment faire. Vu que GTC PC est ligne de commande only, ca devrait pas être très dur de le porter sous linux, si tu arrive a le compiler sur MinGW, tu doit avoir fait le plus dur

s'il arrive a compiler sous mingw, il devrait y arriver sous linux, vu que c le meme compilateur...

Pollux
a écrit : Attendez, je vous programme un compilateur C on-calc et vous me traitez d'égoïste??? C'est le moindre des droits d'un programmeur de choisir la license qu'il veut mettre et/ou ce qu'il veut distribuer. Qui irait traiter PpHd ou BlueZ d'égoïstes parce qu'ils n'ont pas releasé les sources de Genlib, SMA ou Bomberman?

Déjà, c'est faux pour SMA, et puis je peux te donner un nom qui répond à ta question à coup sûr: Richard Stallman. Va faire un tour sur http://www.gnu.org/philosophy/.

Pourtant, ils ont bcp fait avancer la communauté, et ce serait un tort que de cracher sur leur travail.

Ça dépend de si tu considères que sortir des logiciels non-libres et même dont les sources ne sont pas données du tout est "faire avancer la communauté" ou pas.

Ensuite, je ne crois pas que le fait de releaser les sources de GTC ait la moindre utilité : qui est allé corriger les bugs de CC, alors que la source est disponible sur Internet depuis plus de 6 mois?

Il y a déjà moi qui ai recompilé CC en _nostub avec GCC 3.3. Ça ne m'aurait pas été possible sans les sources.

Alors je ne vous dis pas que trouver un volontaire pour faire un algorithme d'allocation de registre plus efficace que celui de GTC tout en étant aussi rapide et aussi peu gourmand en mémoire, ça va pas être du gâteau

Mais quelqu'un intéressé en du vrai passage par registres (pas celui très limité permis par ton allocateur actuel) voudrait certainement au moins essayer de se pencher sur cette question. Sans les sources, il ne peut pas le faire.

La seule chose qu'apporterait l'open-source, si par hasard quelqu'un avait le courage de se plonger dedans - et c pas gagné -, serait d'une part qu'il y aurait bcp de bugs cachés (et oui, c'est très délicat de modifier GTC si on ne connaît pas exactement les conventions qui se cachent dessous, et le moindre contributeur peu attentif pourrait casser pas mal de programmes => des heures de debug),

Il pourrait aussi corriger les bogues qui y sont déjà. Même après des mois de bêta-tests privés, il peut toujours y avoir des bogues!

et d'autre part qu'il y aurait probablement une multitude de versions (il y a un gros tas de #ifdef dans GTC que l'on peut activer/désactiver, donc on peut "customizer" GTC presque à volonté), et résultat il y aurait plein de versions plus ou moins incompatibles, avec une qualité d'optimisation très variable, etc... bref ça serait le bordel

Et ça dérange qui exactement?
Et puis, comme tu dis toi-même que pas grand monde aura envie de s'y plonger, pas grand monde aura envie de sortir sa propre version, donc il n'y aura pas beaucoup de versions.
À titre d'exemple: tout le monde est libre de forker TIGCC, mais personne ne l'a fait.

En plus, je m'engage à corriger tous les bugs que vous trouvez (qd GTC sera sorti bien sûr ), donc je ne vois vraiment pas de quoi vous vous plaignez Très sincèrement, je ne vois pas quelle fonction on pourrait avoir envie de rajouter à GTC, qui ne soit ni trop lente ni trop gourmande en mémoire (à part les opérandes passées aux asm(), mais ça arrive)

Tout ce que TIGCC permet et que GTC ne permet pas! Qui te dit que personne ne trouvera une implémentation efficace pour ce pour quoi tu n'en as pas trouvée? Tu n'es pas parfait!

Pollux a écrit :
> si tu en as marre de l'égoïsme, utilise un logiciel libre: vive TIGCC!
lol vu les giga-octets à télécharger avant de pouvoir compiler TIGCC, on peut pas vraiment dire qu'il soit libre

Pfff, n'importe quoi! Déjà, les sources de TIGCC font une douzaine de MO en tout. C'est très loin même d'un GO, donc tu as à très tort de parler de plusieurs GO. Et puis, personne ne t'empêche de télécharger ça. Tu penses que je fais quoi, moi, pour sortir les prereleases de GCC 3.3 (et aussi les versions de GCC dans les releases officiels de TIGCC)? Je télécharge plusieurs MO sur le site de GCC, je vire ce qui n'est pas nécessaire pour TIGCC (et oui, on fait notre possible pour réduire vos téléchargements au minimum, mais vous ne retenez même pas nécessaire de nous remercier pour cela, au contraire!), je patche, je compile, et j'uploade les sources réduites au minimum, le patch mis à jour et les binaires. Celui qui voudra modifier notre portage de GCC aura exactement la même chose à faire, sauf qu'il pourra partir des sources déjà réduites au minimum, donc il aura moins à télécharger que moi! Alors arrêtez de raconter que ce n'est pas faisable.

Et je vais répéter ce que bcp de monde a dit (surtout Thibaut ), mais vu la propagande de la TIGCC Team pour imposer ses idées, on ne peut pas vraiment parler de logiciel libre

N'importe quoi! Personne ne vous empêche de forker TIGCC, si ce n'est votre paresse.

Mais n'importe quoi!
1) Je ne vois rien de volontairement incompatible. La seule incompatibilité avec TIGCC est la syntaxe asm, mais ça c'est dû à une différence de fonctionnement interne et je n'y peux rien, à moins de rajouter 20 ko au compilo, ce dont je n'ai aucune envie.

Il y a aussi:
* les extensions GNU que tu n'as pas implémentées (cf. point 2),
* les extensions incompatibles que tu as rajoutées.
Ça fait des incompatibilités dans les 2 sens, que tu essayes toujours (à tort!) de nier.

2) "implémentation partielle du GNU C" : à part, encore une fois, les opérandes pour l'ASM inline qui va arriver, il n'y a rien, à ma connaissance, qui soit assez utile pour valoir les ko de compilo, les dizaines de ko de RAM et les secondes de compilation supplémentaires qu'il faudrait pour qu'elle marche

Tu ne le trouves peut-être pas "utile", mais ça ne change rien au fait que ça existe!

3) closed-source : cf post précédent, il n'y a vraiment aucune utilité.

Cf. réponse au post précédent.

Kevin> Certain on parlé ya qq temps de peut etre forker TIGCC, qd on a vu ta réponse, ct pas aussi "entousiaste" qu'actuellement, tu etait meme contre..

Pollux a écrit :
> Tu ne voulais pas rajouter un #macro ou quelque chose dans le genre ? Si, mais je ne sais pas encore si je vais l'inclure tel quel ou pas : étant donné que le préprocesseur C et le préprocesseur ASM sont les mêmes (encore une fois, je le répète, par souci de place, et en plus il se trouve que c'est bien plus pratique parce que les #define's sont en commun)

Et il se trouve que c'est gratuitement incompatible avec TIGCC, mais évidemment, tu t'en fiches de cela.

et que #macro est presque indispensable pour l'ASM,

1. En quoi est-il indispensable pour l'ASM de pouvoir mettre des directives du préprocesseur dans une macro? Pour le reste, #define suffit largement.
2. Même si tu trouves une réponse au 1., ça ne fait que montrer que c'est une mauvaise idée d'utiliser le préprocesseur C pour l'assembleur.

je vais peut-être déconseiller fortement l'utilisation de #macro en C, pour permettre la compatibilité avec TIGCC. D'ailleurs, encore un avantage de ne pas avoir sorti de pré-version de GTC : je peux modifier les extensions comme je veux, sans créer d'incompatibilités dans les sources (par exemple, j'ai déjà changé la syntaxe qui était "asm { ... }" en "asm { ... };", alors que si GTC était sorti avant, soit toutes les sources auraient été rendues incompatibles, soit je n'aurais pas pu rendre la syntaxe plus logique).

Plus logique??? Tu appelles ça logique de devoir mettre un ; après un }??? Normalement, un } termine déjà un bloc en C, donc le ; n'est pas nécessaire. Ta syntaxe pour l'assembleur inline (en plus d'être gratuitement incompatible avec GCC) est très bizarre de par ce fait.

> t'abuse la s'il était pas vraiment libre TIGCC n'aurait jamais vu le jour. Oui, GCC est libre, et il a permis à TIGCC de voir le jour (je ne critique pas l'open-source, bien au contraire). Mais on peut pas dire de TIGCC qu'il est vraiment libre.

Et pourquoi???

> Le porter sous linux est un des idées qui me vient, ou une nouvelle fonctionalité du kernel qui nécessite une modification du linkeur... C vrai que c un peu dommage pour linux, même si ça ne reste pas une priorité... Est-ce que c possible de publier des binaires pour une plate-forme donnée (x86 par exemple), indépendamment de la config précise (version de Linux, etc...), ou est-ce que les sources sont indispensables?

Pour du x86-only, c'est possible (linke tout statiquement), mais Linux n'est pas que du x86!!! C'est pour ça qu'il faut les sources.

XDanger
a écrit : Je parie qu'on va encore entendre parler du comportement de la TIGCC Team et gnagnagna (pas forcément de la part de Pollux, mais de la part de Thibaut ou de personnes du même genre)...

Thibaut a écrit :
Gagné ! et si on est pas mal à le penser, il faudrait peut-être que vous vous demandiez si vous n'êtes pas effectivement un petit peu en tort

1. À part toi, il n'y a pas grand monde à être suffisamment idiot pour répéter ce genre de stupidités dépourvues de sens.
2. Même si vous étiez "pas mal": Si pas mal de gens ont tort, ça ne changera rien au fait qu'ils ont tort! Le nombre ne fait pas la vérité!

godzil
a écrit : Kevin> Certain on parlé ya qq temps de peut etre forker TIGCC, qd on a vu ta réponse, ct pas aussi "entousiaste" qu'actuellement, tu etait meme contre..

Je suis contre, mais je ne peux pas vous l'interdire! C'est ça le logiciel libre!

Ça dépend de si tu considères que sortir des logiciels non-libres et même dont les sources ne sont pas données du tout est "faire avancer la communauté" ou pas.

Une lib comme genlib fait avancer la communauté car même si elle n'est pas open source elle permet de faire des jeux puissants. Il en irait de même pour un compilateur on-calc

Il y a déjà moi qui ai recompilé CC en _nostub avec GCC 3.3. Ça ne m'aurait pas été possible sans les sources.

On peut pas dire que ca ait été un grand bon en avant si tu veut parler de truc utile pense plustôt a 'oups je sais plus désolé' qui essaie de gerer les lib statiques.

À titre d'exemple: tout le monde est libre de forker TIGCC, mais personne ne l'a fait.

Disons que si on fait ca ont se fait engueler par une team qui défend l'open source

et oui, on fait notre possible pour réduire vos téléchargements au minimum, mais vous ne retenez même pas nécessaire de nous remercier pour cela, au contraire!

TIGCC est vraiment open-source te remercie ainsi que toute la team mais si tu était un peu plus gentil envers certains gros projets ambitieux autres que TIGCC, on passerai plus de temps a te remercier de TIGCC et pas défendre ceux que tu attaque plus ou moins justement.

N'importe quoi! Personne ne vous empêche de forker TIGCC, si ce n'est votre paresse.

Quand l'idée a été proposée(je sais plus trop quand), tu était loin d'être aussi d'accord, tu parlais même a un moment de restreindre la liscence.

Ça fait des incompatibilités dans les 2 sens, que tu essayes toujours (à tort!) de nier.

Il ne les nie pas: relis plus attentivement : il dit juste a raison qu'elles ne sont pas primordiales(95% des programmeurs ne l'utilisent pas et elles ne sont pas standard) par rapport a leur cout.

Uther Lightbringer
a écrit : Une lib comme genlib fait avancer la communauté car même si elle n'est pas open source elle permet de faire des jeux puissants.

... si tu acceptes de l'utiliser, malgré le fait qu'elle n'est pas libre. Ce n'est pas le cas de tout le monde (cf. Richard Stallman et la philosophie GNU).

On peut pas dire que ca ait été un grand bon en avant

Bah, pour moi si. Là encore, il y a des gens qui n'acceptent pas d'utiliser un logiciel qui nécessite un kernel (va voir un peu sur les forums internationaux, il y en a!), donc pour eux, ce n'est que depuis mon portage qu'ils peuvent l'utiliser.

Il ne les nie pas: relis plus attentivement : il dit juste a raison qu'elles ne sont pas primordiales(95% des programmeurs ne l'utilisent pas

Chiffre sorti au hasard et pas justifié -> poubelle.

et elles ne sont pas standard)

Pas toutes. À titre d'exemple: GTC ne comprend pas (ou du moins ne comprenait pas aux dernières nouvelles que j'ai):
for (int i=0;i<100;i++)
qui est prévu par le standard ISO C99!

par rapport a leur cout.

Si Pollux ne sait pas les implémenter de manière efficace, c'est son problème personnel, ce n'est pas un problème avec les extensions.

le C99 a été rejeté par bcp de programmeurs C car apportant plein de choses plus inutiles les unes que les autres au languages C, l'adoption de la norme C89 (C ANSI) a été une bonne chose, l'adoption du C99 en est une autre.

faire un

for(int i=0;i<100;i++=

est peut etre la chose la plus crade qu'il m'a jamais été donné de voir en C...

Deja que faire un truc genre

int mafunc()
{
 int i;
[...]
 {
  int i;
  [...]
 }
[...]
}

Qui est autorisé en C++ et C99 c'est immonde alors se for...

... si tu acceptes de l'utiliser, malgré le fait qu'elle n'est pas libre. Ce n'est pas le cas de tout le monde (cf. Richard Stallman et la philosophie GNU).

Moi j'accepte et je pense ne pas être le seul. Bien sur j'aurais préféré avoir les sources mais c'est déja bien d'avoir des outils qui fonctionnent et efficaces.

Bah, pour moi si. Là encore, il y a des gens qui n'acceptent pas d'utiliser un logiciel qui nécessite un kernel

bah c'est leur problème, l'argument de place ne tient même pas car avec la version nostub il perdent plus que la taille du kernel et ne va pas me parler de GCC3.3 ou de ppg car c'est aussi tout a fait possible en kernel.

Chiffre sorti au hasard et pas justifié -> poubelle.

Certes mais je n'ai jamais vu un seul source C qui les utilise à part ceux de la TICT.

qui est prévu par le standard ISO C99!

le C99 est loin d'être encore un véritable standard alors avant de crier a l'horreur parceque GTC ne respecte pas le C99 regarde ca: http://gcc.gnu.org/gcc-3.3/c99status.html

Si Pollux ne sait pas les implémenter de manière efficace, c'est son problème personnel, ce n'est pas un problème avec les extensions.

Pollux n'a pas les même contraintes que toi.

godzil
a écrit : le C99 a été rejeté par bcp de programmeurs C car apportant plein de choses plus inutiles les unes que les autres au languages C, l'adoption de la norme C89 (C ANSI) a été une bonne chose, l'adoption du C99 en est une autre.

Ça ne change rien au fait que le C99 est un standard (et que GCC le supporte presque entièrement, et qu'ils travaillent sur le support 100% parce que personne n'a le droit de juger des parties d'un standard ISO "inutiles"), qu'il y a des programmeurs (dont moi) qui l'aiment bien, et que le standard ISO C90 (ANSI C89) n'est plus un standard ISO (c'est-à-dire qu'un compilateur ISO C90 (ANSI C89) n'est plus un compilateur C).

faire un

for(int i=0;i<100;i++)
est peut etre la chose la plus crade qu'il m'a jamais été donné de voir en C...

Et pourquoi?

Deja que faire un truc genre

int mafunc()
{
 int i;
[...]
 {
  int i;
  [...]
 }
[...]
}

Qui est autorisé en C++ et C99 c'est immonde alors se for...

Je te signale que le code que tu viens de donner est de l'ISO C90 (ANSI C89) parfaitement valide!

le C99 a été rejeté par bcp de programmeurs C car apportant plein de choses plus inutiles les unes que les autres au languages C, l'adoption de la norme C89 (C ANSI) a été une bonne chose, l'adoption du C99 en est une autre.

J'ai lu une partie des extension GNU, certaines sont vraiment pratiques comme les commentaire C++, ASM(quoique discutable) mais la pluspart et sutout celles que tu reproches a Pollux sont pas vraiment propres et n'apportent pas grand chose d'utile.

Uther Lightbringer
a écrit : l'argument de place ne tient même pas car avec la version nostub il perdent plus que la taille du kernel et ne va pas me parler de GCC3.3 ou de ppg car c'est aussi tout a fait possible en kernel.

On prépare une surprise à ce sujet-là, mais je n'ai pas trop envie de l'annoncer maintenant. (Petit indice: Quel est le composant qu'on est en train de réécrire pour TIGCC 0.95 et que pourrait-il apporter pour résoudre ce problème? Je te laisse réfléchir là-dessus.)

Uther Lightbringer
a écrit : J'ai lu une partie des extension GNU, certaines sont vraiment pratiques comme les commentaire C++, ASM(quoique discutable) mais la pluspart et sutout celles que tu reproches a Pollux sont pas vraiment propres et n'apportent pas grand chose d'utile.

Attention, ne mélange pas extensions GNU et nouveautés du C99. Ils se recoupent sur certains points (commentaires C++ par exemple), mais ce sont quand-même des ensembles différents!

On prépare une surprise à ce sujet-là, mais je n'ai pas trop envie de l'annoncer maintenant. (Petit indice: Quel est le composant qu'on est en train de réécrire pour TIGCC 0.95 et que pourrait-il apporter pour résoudre ce problème? Je te laisse réfléchir là-dessus.)

Si je comprend bien vous n'utiliserez plus les standards de TI? Il me semblait que c'était un crime selon toi ca.

non en C89 il est interdit de déclarer une variable autre pars qu'au début d'une fonction d'ailleur le support de code dans entre accolades en dehors d'une déclaration if,for,while est pas "legale" en C89..

ex:

void func()
{
 int i;
 i++;
 {
  i++;
 }
}

n'est pas autorisé en C89 si tu trouve un compilo dit "C89" qui accepete sa c'est qu'il n'est pas C89, les commentaires C++ (//) ne font pas partit aussi du C89 d'ailleur. mais quel compilo C ANSI actuel ne les supportent pas ?

et pourquoi instancier une variable dans un for est crade ?

Va debugguer sa et vive les effet de bords majestueux !
Plus on avance, et plus le C deviens permissif et ajoute des truc inutiles, et qui viennent pourrirs le code..

Personnelement, et je sais ne pas etre le seul, les extentions GNU et le C99 font partit des pire trucs qu'on ai jamais pu voir au niveau languages de programmation au niveau permisivité... le language C qui est pas forcement simple au premier abord deviens de plus en plus immonde... connaisant le style de certain programmeurs le codage en C vadevenir horrible a reprendre... D'ailleur se que j'ai du mal a comprendre c pourquoi il cherchent tant a mettre ses c*****ie d'extention du C++ au C standard... le C et le C++ se ressemblent mais ne sont pas le meme language...

Uther Lightbringer
a écrit : Si je comprend bien vous n'utiliserez plus les standards de TI? Il me semblait que c'était un crime selon toi ca.

Ça sera en option. Probablement désactivé par défaut, mais ce n'est pas encore décidé de manière définitive. Et je précise que je ne promets rien. On a ça en train de marcher (ou du moins d'avoir l'air de marcher) dans la version alpha, mais c'est tout ce que je peux dire de manière certaine.

et c quoi ?

He bien aparament ils feraient les relogement comme le kernel. Bref le nostub TIGCC est bien de plu en plus en train de devenir un kerstub, sauf que le "kerstub" est inclu dans chaque programme.

arf, oue, ok...
bah, ca fait longtemps que le nostub n'est plus nostub... (sauf a moins de vraiment maitriser les defines )

Je suis comme godzil... un langage qui permet la déclaration de variable "à l'arrache" est pour moi une hérésie. Je le comprends (mais je ne le cautionne pas) pour un langage comme le Basic qui sert plus à de petites applis qu'à autre chose, mais venant du C, c'est une hérésie (je sais, je me répète) ne serait-ce que du point de vue analytique.