godzil
a écrit : 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..
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ tigcc --version
GCC.EXE (GCC) 3.3 20030421 (TIGCC prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ cat test6.c
void func()
{
int i;
{
int i;
}
}
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ tigcc -ansi -pedantic-errors -S test6.c
unknown@K /e/TI-89/Compilers/tigcc/Projects
$
ex:void func() { int i; i++; { i++; } }n'est pas autorisé en C89
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ tigcc --version
GCC.EXE (GCC) 3.3 20030421 (TIGCC prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ cat test6.c
void func()
{
int i;
i++;
{
i++;
}
}
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ tigcc -ansi -pedantic-errors -S test6.c
unknown@K /e/TI-89/Compilers/tigcc/Projects
$
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 ?
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ tigcc --version
GCC.EXE (GCC) 3.3 20030421 (TIGCC prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ cat test6.c
// Main Function
void _main(void)
{
}
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ tigcc -ansi -pedantic-errors -S test6.c
test6.c:1: error: parse error before '/' token
unknown@K /e/TI-89/Compilers/tigcc/Projects
$ tigcc -pedantic-errors -S test6.c
test6.c:1:1: C++ style comments are not allowed in ISO C90
test6.c:1:1: (this will be reported only once per input file)godzil a écrit :
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...
Je suis comme godzil... un langage qui permet la déclaration de variable "à l'arrache" est pour moi une hérésieVB ne le permet pas et pourtant c'est le genre de langage ou ca pourait être compréhensible. en JAVA ca ne gène pas non plus mais a mon avis le C doit rester un langage simple et proche de la machine avec une structure fixe et les extension ne vont pas dans le bon sens.
Uther Lightbringer
a écrit : VB ne le permet pas
Moi, je ne l'utilise pas en tout cas. Et ça permet d'utiliser la déclaration "en passant", en attachant l'identifiant du type ($, %, &, ...) à la première utilisation de la variable.
(euh d'ailleurs tu parles d'une douzaine de Mo, c'est très loin d'être vrai : j'avais voulu compiler TIGCC il y a assez longtemps, j'avais téléchargé une 30aine de Mo et j'avais fini par me décourager - sincèrement, prends Windows fraîchement installé et essaye de télécharger le minimum nécessaire pour recompiler TIGCC : tu vas voir que ça fait vraiment beaucoup, évidemment moins d'un Go, mais bcp)
)
)
Thibaut a écrit :
> À titre d'exemple: tout le monde est libre de forker TIGCC, mais personne ne l'a fait.
Personne ne le fait parceque si on annonce qu'on veut le faire, y'a un Monsieur au comportement extrêment bizarre, soi-disant pour le logiciel libre, qui nous en empêche.
> 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
>> 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!
Il est certainement plus parfait que toi. Il n'emmerde pas ceux qui ne sont pas d'accord avec lui. Il a été capable de faire quelque chose de bien plus utile et compliqué qu'un backgammon.
Il est assez bon programmeur, je pense, pour savoir si ces extensions sont implémentables sans ajouter des dizaines de ko de binaire. Tu penses bien que ces extensions ne peuvent pas tenir sur quelques octets ! Tsss...
> 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.
Bordel, mais tu sors d'où pour ne pas savoir que la taille des fichiers est limitée à 64 ko (avec une DLL on aurait plus assez de RAM libre) sur TI68k ???
Arrête d'emmerder le peuple, tu sais que c'est impossible ! Il est évident que GTC ne peut pas prendre en compte TOUTES les fonctionnalités de TIGCC,
et qu'il doit en inventer d'autres moins gourmandes en ressources pour compenser.
Ceux qui ne veulent pas de ces extensions ne les utiliseront pas (combien de fois on va te le répéter).
Il faut faire des choix entre les possibilités qu'on permet et ce qu'on retire parceque c'est moins indispensable.
C'est pour ça qu'il est débile de rejeter GTC. Il est très fonctionnel, mais il y a des limites qui ne dépendent pas de Pollux. Programme un compilateur on-calc, tu buteras sur les mêmes limites. Tu trouverais juste qu'on dise "ton compilo est une merde" pour ça ? Non, car il rendra quand même de grands services.
> ça ne fait que montrer que c'est une mauvaise idée d'utiliser le préprocesseur C pour l'assembleur.
Encore un fois, il n'a pas le choix s'il veut gagner autant de place que possible.
> Mais on peut pas dire de TIGCC qu'il est vraiment libre.
>> Et pourquoi???
Quelle mauvaise foi.
> 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é!
Ben voyons, on a tort ! Oui, on a tort quand on dit que vous nous empêchez de faire notre propre TIGCC,
on a tort quand on dit que vous employez les moyens les plus lamentables pour salir la réputation d'un programme qui utilise les DLLs comme vous ne l'aviez pas prévu...
> 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.
Parceque toi tu as la faculté de compresser les centaines de lignes de code nécessaires en 3 lignes afin de ne pas dépasser 64 ko ? Pffff, quel festival de mauvaise foi aujourd'hui !
> c'est-à-dire qu'un compilateur ISO C90 (ANSI C89) n'est plus un compilateur C
C'est quoi alors ? un compilateur Pascal ?
Zut, je vais devoir apprendre un nouveau langage !
Pollux
a écrit : Juste une précision, GTC fait bien plus de 64k (100k actuellement), mais en pratique il prend bien moins de place que CC (assembleur intégré, header compressé...) Le problème n'est donc pas la limite des 64k, mais de rester à une taille correcte, avoir une vitesse d'exécution correcte et ne pas demander trop de RAM (sinon on ne pourrait pas compiler de grosses fonctions, même si actuellement on peut compiler des fonctions ~ 2-3 fois plus grosses qu'avec CC)
> C'est très loin même d'un GO, donc tu as à très tort de parler de plusieurs GO
lol(euh d'ailleurs tu parles d'une douzaine de Mo, c'est très loin d'être vrai : j'avais voulu compiler TIGCC il y a assez longtemps, j'avais téléchargé une 30aine de Mo et j'avais fini par me décourager - sincèrement, prends Windows fraîchement installé et essaye de télécharger le minimum nécessaire pour recompiler TIGCC : tu vas voir que ça fait vraiment beaucoup, évidemment moins d'un Go, mais bcp)
> 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. Appels récursifs, tests sur les arguments (exemple : utilisation d'argument variables et génération de code en conséquence)
> 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.
Cf posts précédents
> 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. Non, par exemple : enum { VAL1, VAL2, VAL3 };
Et je pense que si tu avais dirigé la team GCC au moment d'introduire ({...}), tu aurais violemment critiqué une extension aussi saugrenue (des parenthèses autour d'un bloc, on aura tout vu
> ... 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
As a computer user today, you may find yourself using a proprietary (18k characters) program. If your friend asks to make a copy, it would be wrong to refuse. Cooperation is more important than copyright. But underground, closet cooperation does not make for a good society. A person should aspire to live an upright life openly with pride, and this means saying ``No'' to proprietary software.
> 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.
Puisque tu es si fort, si tu trouves un moyen d'implémenter dans CC les fonctions inline ou les nested functions en moins de 1 ko et sans surcoût de mémoire ou de vitesse, je veux bien porter tes routines pour GTC (mais j'ai comme un doute
Kevin Kofler a écrit :
Ce n'est pas drôle. Je cite:
>As a computer user today, you may find yourself using a proprietary (18k characters)
>program. If your friend asks to make a copy, it would be wrong to refuse. Cooperation is
>more important than copyright. But underground, closet cooperation does not make for
>a good society. A person should aspire to live an upright life openly with pride, and this
>means saying ``No'' to proprietary software.
Un compilo on-calc n'a pas les mêmes contraintes qu'un compilo PC, point. Arrête de relancer le débat alors que tu sais pertinemment que tu vas demander à GTC des choses impossibles pour un compilo on-calc.
D'ailleurs tu dois avoir Windows sur ton ordinateur donc tout ça c'est des paroles en l'air
Le truc spécial, c'est le nouvel éditeur de liens je crois
a vérifierC'est quoi le standart par défaut utilisé par TIGCC ? Parce que j'ai du mal comprendre, mais j'ai l'impression que c'est des bouts de standarts pris d'un peu partout ? D'après la doc, j'ai cru comprendre que le standart par défaut est du C89, avec des extensions GNU (donc non standart) et quelques extensions prises du C99.Le standard de TIGCC c 'est le GNU C, c'est a dire le C89 + les extentions GNU(dont certaines sont reprises dans le C99) GCC tend a évoluer vers le C99.
> Le truc spécial, c'est le nouvel éditeur de liens je crois. ("éditeur de liens" == "linker")?TRUE:FALSETRUE
g cru entendre parler d'une modification au niveau des tables de relogemenst a vérifierje pense qu'il doit implémenter une table de relogement style kernel vu qu'il a dit que ca corrigerai le retard en taille de CC par raport au kernel et que c'est justement la table de relogemment kernel qui lui permet d'économiser de la place. De plus il n'a pas nié le fait que ca serait incompatible avec le format nostub standard.
*** : extension indispensable ou extrêmement courante
** : extension souvent utile, mais dont on peut se passer
* : extension d'un intérêt limité
: extension a priori inutilisée ou alors rarissime
nom de l'extension | utilité | implémenté?
-----------------------------------------------------------------------
Statements and Declarations in Expressions *** oui
Labels as Values * non
Nested Functions ** non (on s'en passe très bien mais le portage n'est pas immédiat)
Referring to a Type with 'typeof' ** oui
Generalized Lvalues ** 80% (pas les détails exotiques genre (a,b)+=5)
Conditionals with Omitted Operands * oui
Double-Word Integers ** non
Complex Numbers non
Arrays of Length Zero *** oui
Arrays of Variable Length * non
Macros with Variable Numbers of Arguments *** oui
Non-Lvalue Arrays May Have Subscripts euh?
Arithmetic on void- and function- pointers *** oui
Non-Constant Initializers ** oui
Constructor Expressions (Cast Constructors) ** oui
Labeled Elements in Initializers ** oui
Cast to a Union Type * non
Case Ranges ** oui
Declaring Attributes of Functions *** oui
C++ Style Comments *** oui
Dollar Signs in Identifier Names * oui
The Character ESC in Constants oui
An Inline Function is As Fast As a Macro ** non
Assembler Instructions with C Expression Operands ** non
Variables in Specified Registers non
Alternate Keywords oui
Getting the Return or Frame Address of a Function non
Other built-in functions provided by GNU C oui
Et les extensions complètement inutiles, soit parce que ce sont des extensions
de compatibilité très pointues avec les vieux standard (ce qui n'est pas nécessaire
sur TI), soit parce qu'elles n'ont aucune signification dans GTC (N/A), soit parce
qu'elles n'ont jamais et/ou ne seront certainement jamais utilisées...
Locally Declared Labels non
Naming an Expression's Type deprecated?
Constructing Function Calls non
Hex Floats non
Prototypes and Old-Style Function Definitions euh?
Inquiring on Alignment of Types or Variables non
Incomplete 'enum' Types euh?
Function Names as Strings non
Specifying Attributes of Variables N/A
Specifying Attributes of Types N/A
Controlling Names Used in Assembler Code N/A
mais c clair que c impossible à recompiler. Je suis sûr que personne sur le forum (sauf Kevin ) n'a essayé de le recompiler...