Guru of the week #86 - Page 1

Hmmm oui rien de neuf je sais, mais je les lis avec beaucoup de retard, et celui du jour (entendre : de y'a 3 ans) m'a bien amusé.

Guru Questions

Answer the following questions without using a compiler.

1. What is the output of the following program on a standards-conforming C++ compiler?

    #include <iostream>
    #include <iomanip>

    int main()
    {
      int x = 1;
      for( int i = 0; i < 100; ++i );
        // What will the next line do? Increment???????????/
        ++x;
      std::cout << x << std::endl;
    }

2. How many distinct errors should be reported when compiling the following code on a conforming C++ compiler?

    struct X {
      static bool f( int* p )
      {
        return p && 0[p] and not p[1:>>p[2];
      };
    };

Voilà. Le 1. est assez facile, le second est....bah plus space quoi

je suit pas trop la STL du C++ et je vois pas trop ce que (peux) faire le code du 2, si ce n'est que perso "and" "not" ne sont pas des mots clef du C/C++

:>> me semble pas valide non plus

le fait que la fonction soit static je vois pas trop non plus

Appres 0[p] c'est tres tres crade

apres je dirais bien

1 static , 2 0[p], 3 and, 4 not, 5, :>>, 6 le manque d'un ] a la fin

donc 6 erreurs ? (au minimum)

Groumpf :

iBookG4:~ godzil$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250)
Copyright (C) 2005 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.
iBookG4:~ godzil$ cat > pwet.cpp << EOF
> struct X { 
>       static bool f( int* p ) 
>       { 
>         return p && 0[p] and not p[1:>>p[2]; 
>       }; 
>     };
> EOF
iBookG4:~ godzil$ g++ pwet.cpp -c
iBookG4:~ godzil$ 

Je pense que le static n'est pas une erreur.
Le 0[p] je ne comprends même pas comment ça peut passer (integer to pointer without a cast, et la même chose en sens inverse)
Le :>>, pour moi ce n'est pas du C++ non plus
and et not, je crois bien que ce sont des mots-clés C++ rajoutés dans les derniers standards


Bref, comprends absolument pas comment ça peut passer, même en -Wall -W -O2 -ansi -pedantic...

re ça aussi en C (a[ b] est toujours interprété comme *(a + b)). C'est d'ailleurs parfois pratique pour éviter d'avoir à forcer la priorité avec des parenthèses :char *ptr; ... 2[(short*)ptr] = 5; 0[p] ça m'étonne pas trop, on peut fai

Le :>> c'est vrai que c'est louche...

Tout comme 'and' est équivalent à '&&' et 'not' équivalent à '!', ':>' est équivalent à ']'.

Extended: ça n'explique pas pourquoi ça parvient à le faire sans le moindre warning, alors qu'un pointeur est utilisé comme index...

Nitro: Elle vient d'où, cette dernière correspondance ?

Link :
Extended: ça n'explique pas pourquoi ça parvient à le faire sans le moindre warning, alors qu'un pointeur est utilisé comme index...

C'est pas pointeur[pointeur], c'est entier[pointeur], donc c'est parfaitement sûr et je ne vois pas pourquoi il faudrait un warning pour ça ? C'est pas plus choquant que la différence entre "x == 0" et "0 == x" ^^

bah si tu sais pas que p[i] <=> *(p + i)
bah, tu sais pas hein

Bah cf ./4.

nEUrOO :
bah si tu sais pas que p[i] <=> *(p + i)
bah, tu sais pas hein

Oui, ça peut éventuellement "surprendre" au sens où on ne comprend pas ce que le code veut dire et on est obligé de se renseigner pour le comprendre, mais contrairement à d'autres choses du style a << b + c ça ne peut pas aboutir à une fausse interprétation du code, donc à mon avis c'est vraiment pas grave et pas franchement digne d'un warning... (même si un warning ne serait probablement pas très gênant, je ne crois pas qu'il apporte quoi que ce soit)

Link
: Nitro: Elle vient d'où, cette dernière correspondance ?

C'est indiqué dans la norme.
Perso dans mon bouquin "Le langage C++", de Bjarne Stroustrup, c'est donné page 926.
Bon, c'est vrai faut être un geek pour lire ces pages là....

En fait, ce que je demandais, c'est pas trop dans quelle norme c'était, mais comment et pourquoi ça y est entré...
Car ce n'est pas du tout intuitif...


Peut-être une compatibilité avec un autre langage plus ancien (et tout aussi peu intuitif) ?

C'est pour les personnes qui utilisent un jeu de caractère sans [ et { (entre autres).

Merci.

Oui, ça s'appelle un trigraph.

Sinon, la réponse pour le 1) c'est que le programme va afficher 1
La réponse pour le 2) c'est que c'est un code parfaitement valide.

Mais ce que j'aime avec ces réponses, c'est qu'elles sont loin de cloturer le sujet, parce que pour trouver tous les morceaux y'en a pour un bon moment.

heu

0[p] sur des chars ok, mais meme sur d'autres types ça marche ??

0[p] correspond a partir de l'addresse 0 et prendre la p^eme case mémoire, autant pour le premier je veux bien que ça marche, mais si on veux recuperer la seconde donnée par ex :

struct p_ {
 int a,b,c;
} p;

0[p] == p[0]

ça risque pas de poser des pbms d'alignements ? (ou je sais pas quoi d'autres)

si 0 est casté en un type tenant sur un octet, ça marche tres bien, si c'est pas le cas, ça va poser problème :

Si le compilo caste le 0 (et le 2) comme etant de type 'struct p_', il va aller avec 0[p] a l'addresse (sizeof(struct p_)*p)+0 dans le case de 0[p] a cause de l'arithmetique des pointeurs...

Justement non, le 0 n'est casté en rien du tout, il est considéré comme un véritable entier, qui sera ajouté au pointeur (selon les règles de l'arithmétique de pointeurs). Du coup 0[p] == p[0] est toujours vrai, et plus généralement x[y] et y[x] sont rigoureusement équivalents...

[EDIT : [0] :/]

Ok

je trouve pas ça forcement tres logique mais bon
ok

Bah moi je vois ça comme ça et ça me semble logique :
x[y] == *(x+y) == *(y+x) == y[x]

Le seul petit problème est au niveau de la deuxième égalité, qui est pas forcément évidente, mais apparemment c'est bon :

Legal operand types for expr1 + expr2 are:

1. Both expr1 and expr2 are of arithmetic type;
2. expr1 is of pointer to object type, and expr2 is of integral type.
3. expr1 is of integral type, and expr2 is of pointer to object type;
... In cases 2 and 3, the rules of pointer arithmetic apply.

BiHi
: Le seul petit problème est au niveau de la deuxième égalité, qui est pas forcément évidente

Bah heureusement que l'addition est commutative en C comme en maths

Ouais mais elle pas associative, c'est encore plus grave

La première question est intéressante aussi. Y'a aussi une astuce qui montre un truc dangereux....pour lequel aucun compilo de génère d'avertissement.

spectras :
Sinon, la réponse pour le 1) c'est que le programme va afficher 1

heu, "2", plutôt, non

spectras>
Bah oui, le whitespace ça peut être trompeur même si c'est ignoré par à peu près tous les compilos...
x = (x * 2) + (x+1 * 2);

(il faut aussi dire que le C(++) n'a pas de fonction d'itération un peu évoluée, du coup n'importe quelle boucle for est tellement bourrée d'information inutile qu'on apprend à en faire abstraction ^^)

Pen^2 :
heu, "2", plutôt, non

Nonon, 1
Essaie si tu me crois pas. T'as bien vu l'une des deux erreurs...mais il y en a une autre.

ben.. :

jmonvill@sgi-gi-s04 ~/Bureau
$ cat huhu.cpp && g++ --version && g++ huhu.cpp -o huhu.exe && ./huhu.exe


    #include <iostream>
    #include <iomanip>

    int main()
    {
      int x = 1;
      for( int i = 0; i < 100; ++i );
        // What will the next line do? Increment???????????/
        ++x;
      std::cout << x << std::endl;
    }

g++ (GCC) 3.2 20020927 (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.

2

huhu.cpp:8:58: warning: trigraph ??/ ignored, use -trigraphs to enable

Il est précisé : avec un compilateur se conformant aux standards. Ce n'est pas le cas de GCC, par défaut.
Essaie avec gcc -ansi je crois que ça doit être ^^

Vi Pollux
Et le trigraph ??/ est équivalent au caractère \
...qui se retrouve en fin de ligne.

Donc le x++ se retrouve commenté ^^

ah ok.. ça saute pas tellement aux yeux à vrai dire (j'avais remarqué le '/' à la fin du commentaire mais je n'avais pas compris pour autant..)