RAAAAAAAAAHHHHHHHHHHHHHHH BORDEL DE MERDE DE GCC!!!! - Page 2

sBibi :
ah ok pour les asm effectivement tu t'en fous...
quelle idee aussi d'avoir cette syntaxe a la con... c'est quand meme mieux ca merde...

__asm
{
rtdsc
mov dword ptr [clock], eax
mov dword ptr [clock + 4], edx
push eax
call truc
...
}
que je sais pas quelle immondice avec gcc et cette foutue syntaxe AT&T (ou un nom du genre)...

sBibi :
ah ok pour les asm effectivement tu t'en fous...
quelle idee aussi d'avoir cette syntaxe a la con... c'est quand meme mieux ca merde...

__asm
{
rtdsc
mov dword ptr [clock], eax
mov dword ptr [clock + 4], edx
push eax
call truc
...
}
que je sais pas quelle immondice avec gcc et cette foutue syntaxe AT&T (ou un nom du genre)...

 __asm ( 
 "rtdsc;"
 "mov dword ptr [%0], %%eax;"
 "mov dword ptr [%0 + 4], %%edx;"
 "push %%eax;"
 "call truc;"
 ... 
 ::"r"(clock):"eax","edx");

 __asm ( 
 "rtdsc;"
 "movl %%eax, (%0);"
 "movl %%edx, 4(%0);"
 "pushl %%eax;"
 "call truc;"
 ... 
 ::"r"(clock):"eax","edx");

du moment que t'as une chaine ou les espaces importent ca sert vraiment a rien.

Pollux
:

Kevin Kofler :
Pas seulement moi! Pas mal d'utilisateurs de TIGCC aussi, et des commentaires sur Slashdot aussi (à chaque newsitem parlant de GCC!).

Oué, enfin les commentaires de Slashdot, c'est pas forcément une référence en terme de pertinence

je pense que les mainteneurs de GCC avaient raison.

Et il y a pas mal d'extensions un peu "expérimentales" et bancales qui doivent être dans le même cas. Celle dont tu parles n'est pas dans ce cas-là, puisqu'elle a le mérite d'avoir une sémantique très claire...

Et les chaînes de caractères multi-lignes, elles n'ont pas une sémantique très claire???

Non, justement. Sous Win32, par exemple, un retour à la ligne doit être traduit par un \r\n ou par un \n ?

Si j'utilise des routines spécifiques à Win32, je vais vouloir le premier choix, et si j'utilise des routines de la libc, ce sera plutôt le deuxième. Malheureusement, le compilo ne peut pas deviner à ma place...

Et il y a aussi les pbs de parsing que ça pose (non pas au niveau du compilo, où c'est une véritable trivialité, mais au niveau d'outils de recherche/manipulation/formattage)

printf("truc\n\
machin\n\
bidule\n\
marmotte\n");

La taille et la vitesse du compilateur ne sont pas ce qu'il y a de plus important... La taille et la vitesse du code produit sont beaucoup plus importants.

Absolument. Mais les multi-line strings n'y changent strictement rien... (j'aurais même tendance à penser que ça l'affecte de manière négative, puisque si je l'utilise dans un contexte où le whitespace n'importe pas (qui est à peu près le seul contexte raisonnable où je peux l'utiliser), je vais rajouter des indentations et des newlines que je n'aurais pas eu en concaténant bêtement les chaînes).

si la feature est utile est tres utilisee (comme c'est le cas la), mieux vaut ne pas la supprimer ni la casser du tout...

vi... mais ce n'est pas le cas des multi-line string literals, par exemple.

Hein???
Cette extension était (et est toujours dans le cas de TIGCC ) utilisée dans des centaines de sources! Même le noyau Linux les utilisait dans tous les sens!

<troll> Cette feature est d'autant plus néfaste qu'elle est utilisée </troll>

Plus sérieusement, je n'ai aucune idée de l'ampleur du travail de conversion, donc je ne peux pas me prononcer : mais je soupçonne que s'ils l'ont fait, ça n'était pas si grave que ça.

Bravo, tu viens de souligner l'un des problèmes clé : c'est carrément _incompatible_ avec un formatage lisible de la source !!!

Ca signifie aussi qu'un éditeur ne peut pas se charger automatiquement de l'indentation pour ces endroits-là sans risquer de changer la sémantique du programme : je trouve ça plutôt flippant...

printf("truc\n\
machin\n\
bidule\n\
marmotte\n");

et les retours à la ligne qui dépendent de la plateforme,

On utilise les retours à la ligne de la plateforme sur laquelle on travaille. C'est bon dans pratiquement tous les cas. (Surtout parce que des trucs comme printf acceptent à la fois \n et \r\n sans problèmes normalement.)

Ca m'étonnerait énormément que \r\n soit tjs accepté en remplacement de \n... Et pour un prog qui n'utilise que l'API portable, ça impliquerait qu'il se mettrait à foirer sous Win32

Oui, mais déterminer si on est dans un commentaire n'est pas forcément indispensable... Par exemple on peut avoir envie de faire grep -i '^([^"]*"(\[^\"]*\[^\"]*)*")[^"]*"(\[^\"]*\[^\"]*)*marmotte' pour avoir la liste de tous les fichiers contenant potentiellement la chaîne de caractères "marmotte", en étant certain de ne pas en rater...

J'ajouterais aussi que le statut d'un commentaire n'est pas tellement différent de celui d'une directive de compilation conditionnelle, donc à moins d'implémenter un test de satisfaisabilité d'une clause (problème NP-complet, hein ), il est impossible de savoir si un bout de code peut potentiellement être parsé par le compilateur ou s'il est mort... (et il m'arrive souvent d'utiliser des #if 0 avec du code syntaxiquement invalide, même si c'est peut-être Mal...)

Kevin Kofler
:

sBibi :
ah ok pour les asm effectivement tu t'en fous...
quelle idee aussi d'avoir cette syntaxe a la con... c'est quand meme mieux ca merde...

__asm
{
rtdsc
mov dword ptr [clock], eax
mov dword ptr [clock + 4], edx
push eax
call truc
...
}
que je sais pas quelle immondice avec gcc et cette foutue syntaxe AT&T (ou un nom du genre)...

La syntaxe asm("") GCC vs. asm {} M$VC n'a strictement rien à voir avec la syntaxe movl src,dest AT&T/GNU vs. mov dest,src Intel/M$. La preuve: les versions récentes de GCC et de GNU as permettent d'utiliser la syntaxe Intel, mais toujours dans des asm(""). Ton code en GCC avec -masm=intel:

 __asm ( 
 "rtdsc;"
 "mov dword ptr [%0], %%eax;"
 "mov dword ptr [%0 + 4], %%edx;"
 "push %%eax;"
 "call truc;"
 ... 
 ::"r"(clock):"eax","edx");

Ton code en GCC standard:

 __asm ( 
 "rtdsc;"
 "movl %%eax, (%0);"
 "movl %%edx, 4(%0);"
 "pushl %%eax;"
 "call truc;"
 ... 
 ::"r"(clock):"eax","edx");

(Soit dit en passant que tu remarqueras la ressemblance frappante avec le 68k...)

du moment que t'as une chaine ou les espaces importent ca sert vraiment a rien.

Si, il suffit de ne pas indenter à l'intérieur.

Pollux
:

Kevin Kofler :
Pas seulement moi! Pas mal d'utilisateurs de TIGCC aussi, et des commentaires sur Slashdot aussi (à chaque newsitem parlant de GCC!).

Oué, enfin les commentaires de Slashdot, c'est pas forcément une référence en terme de pertinence

Écoute, c'est sur des sites comme Slashdot que tu vas trouver des utilisateurs de GCC.

je pense que les mainteneurs de GCC avaient raison.

Et il y a pas mal d'extensions un peu "expérimentales" et bancales qui doivent être dans le même cas. Celle dont tu parles n'est pas dans ce cas-là, puisqu'elle a le mérite d'avoir une sémantique très claire...

Et les chaînes de caractères multi-lignes, elles n'ont pas une sémantique très claire???

Non, justement. Sous Win32, par exemple, un retour à la ligne doit être traduit par un \r\n ou par un \n ?

Le compilateur n'a qu'à utiliser ce qu'il y a dans la source.

Si j'utilise des routines spécifiques à Win32, je vais vouloir le premier choix, et si j'utilise des routines de la libc, ce sera plutôt le deuxième. Malheureusement, le compilo ne peut pas deviner à ma place...

Si, tu n'as qu'à mettre le bon retour à la ligne dans ta source.
Et puis s'il est vraiment important lequel tu mets, autant le coder explicitement. Mais pour printf, une bonne implémentation de printf ignore complètement \r. Du moins pour Win32.

Et il y a aussi les pbs de parsing que ça pose (non pas au niveau du compilo, où c'est une véritable trivialité, mais au niveau d'outils de recherche/manipulation/formattage)

Ce n'est pas plus dur que les "" en une ligne et les escaped-newlines. Regarde par exemple la "correction" proposée pour les logiciels utilisant des chaînes de caractères multilignes:

printf("truc\n\
machin\n\
bidule\n\
marmotte\n");

Voilà, du coup c'est du C ISO/ANSI. Est-ce plus clair? Plus lisible? Plus simple à parser? Moins problématique avec les indentations?

La taille et la vitesse du compilateur ne sont pas ce qu'il y a de plus important... La taille et la vitesse du code produit sont beaucoup plus importants.

Absolument. Mais les multi-line strings n'y changent strictement rien... (j'aurais même tendance à penser que ça l'affecte de manière négative, puisque si je l'utilise dans un contexte où le whitespace n'importe pas (qui est à peu près le seul contexte raisonnable où je peux l'utiliser), je vais rajouter des indentations et des newlines que je n'aurais pas eu en concaténant bêtement les chaînes).

Dans un contexte comme asm, ça n'affecte pas le code généré. Dans un autre contexte, ben tu n'indentes pas à l'intérieur de ta chaîne! Tu mets longtemps à comprendre, toi...

si la feature est utile est tres utilisee (comme c'est le cas la), mieux vaut ne pas la supprimer ni la casser du tout...

vi... mais ce n'est pas le cas des multi-line string literals, par exemple.

Hein???
Cette extension était (et est toujours dans le cas de TIGCC ) utilisée dans des centaines de sources! Même le noyau Linux les utilisait dans tous les sens!

<troll> Cette feature est d'autant plus néfaste qu'elle est utilisée </troll>

Ah, parce que c'est à toi de décider ça. Tu es tout aussi arrogant que les mainteneurs de GCC. Ça promet pour ton compilateur...

Plus sérieusement, je n'ai aucune idée de l'ampleur du travail de conversion, donc je ne peux pas me prononcer : mais je soupçonne que s'ils l'ont fait, ça n'était pas si grave que ça.

S'ils l'ont fait, c'est parce qu'on ne leur a pas laissé le choix!

Bravo, tu viens de souligner l'un des problèmes clé : c'est carrément _incompatible_ avec un formatage lisible de la source !!!

Ben non. On voit tout de suite que si quelque chose traîne au début d'une ligne, on est dans une chaîne de caractères.

         Compute();
         if (x!=y)
           printf("You made a mistake:
%s (%d)",GetErrorStringFrom(x,y,data,foobar),
             GetLineNumber());
         Blah();

Ca signifie aussi qu'un éditeur ne peut pas se charger automatiquement de l'indentation pour ces endroits-là sans risquer de changer la sémantique du programme : je trouve ça plutôt flippant...

Un éditeur n'a pas à indenter à l'intérieur d'une chaîne de caractères! Tu proposes aussi d'indenter à l'intérieur de

printf("truc\n\
machin\n\
bidule\n\
marmotte\n");

, toi?

et les retours à la ligne qui dépendent de la plateforme,

On utilise les retours à la ligne de la plateforme sur laquelle on travaille. C'est bon dans pratiquement tous les cas. (Surtout parce que des trucs comme printf acceptent à la fois \n et \r\n sans problèmes normalement.)

Ca m'étonnerait énormément que \r\n soit tjs accepté en remplacement de \n... Et pour un prog qui n'utilise que l'API portable, ça impliquerait qu'il se mettrait à foirer sous Win32

Si je me rappelle bien, l'API portable (printf etc.) accepte \r\n sans broncher sous Win32...

Oui, mais déterminer si on est dans un commentaire n'est pas forcément indispensable... Par exemple on peut avoir envie de faire grep -i '^([^"]*"(\[^\"]*\[^\"]*)*")[^"]*"(\[^\"]*\[^\"]*)*marmotte' pour avoir la liste de tous les fichiers contenant potentiellement la chaîne de caractères "marmotte", en étant certain de ne pas en rater...

Argh!!! C'est quoi cette horreur de regex?! Je n'ai certainement pas envie de rentrer un horreur comme ça, moi. Moi, si je veux savoir ça, je cherche "marmotte" dans le binaire compilé, c'est plus simple.

J'ajouterais aussi que le statut d'un commentaire n'est pas tellement différent de celui d'une directive de compilation conditionnelle, donc à moins d'implémenter un test de satisfaisabilité d'une clause (problème NP-complet, hein ), il est impossible de savoir si un bout de code peut potentiellement être parsé par le compilateur ou s'il est mort... (et il m'arrive souvent d'utiliser des #if 0 avec du code syntaxiquement invalide, même si c'est peut-être Mal...)

NP-complet != impossible...

Kevin Kofler
: La syntaxe asm("") GCC vs. asm {} M$VC n'a strictement rien à voir avec la syntaxe movl src,dest AT&T/GNU vs. mov dest,src Intel/M$. La preuve: les versions récentes de GCC et de GNU as permettent d'utiliser la syntaxe Intel, mais toujours dans des asm(""). Ton code en GCC avec -masm=intel:

 __asm ( 
 "rtdsc;"
 "mov dword ptr [%0], %%eax;"
 "mov dword ptr [%0 + 4], %%edx;"
 "push %%eax;"
 "call truc;"
 ... 
 ::"r"(clock):"eax","edx");

Ton code en GCC standard:

 __asm ( 
 "rtdsc;"
 "movl %%eax, (%0);"
 "movl %%edx, 4(%0);"
 "pushl %%eax;"
 "call truc;"
 ... 
 ::"r"(clock):"eax","edx");

(Soit dit en passant que tu remarqueras la ressemblance frappante avec le 68k...)

du moment que t'as une chaine ou les espaces importent ca sert vraiment a rien.

Si, il suffit de ne pas indenter à l'intérieur.

<troll> Cette feature est d'autant plus néfaste qu'elle est utilisée </troll>

Ah, parce que c'est à toi de décider ça. Tu es tout aussi arrogant que les mainteneurs de GCC. Ça promet pour ton compilateur...

je pense que les mainteneurs de GCC avaient raison.

Kevin Kofler :
Je suis entièrement d'accord avec toi! Cf. aussi http://b15.ezboard.com/ftichessteamhqfrm13.showMessage?topicID=453.topic.
Je peux réverser ça pour TIGCC et te faire parvenir un patch à appliquer à FSF GCC pour réverser ça, mais c'est tout ce que je peux faire, moi.
Vivement un fork de GCC:
* sans copyright assignments!
* avec une attitude pro-extensions comme dans les "beaux vieux temps"!
* avec un système de patches "no objections means go ahead" (à la KDE) plutôt que des patches qui attendent des mois que quelqu'un bouge son c*l pour les "review"er! Alors, personne pour m'aider à mettre en place un tel fork?