A question bete, reponse idiote

OK, donc c’est un(specifi|defin)ed uniquement quand c’est une expression qui est jugée ambigüe. Dans celles que j’ai données ça devrait donc faire :
a=cc++
b=c
++c
c=c++c++++c
d+=d++
et bien sûr c :slight_smile: non mais :stuck_out_tongue:

[Edité le 17/7/2002 par xentyr]

Hop hop je rajoute donc mon a [ i ] = i++

PS: Sniff mon K&R est resté à Paris :slight_smile: :wink: :wink:

[Edité le 17/7/2002 par xentyr]

Merci count0 pour ta réponse :slight_smile: car je m’orientais vers le unspecified mais dans des cas plus complexes, pas pour un truc aussi simple.

En gros le simple a[ i ]=i++ est undefined donc le compilo fait ce qu’il veut (et d’habitude dans ce cas-là, il fait bien ce qu’on lui demande)

Ca sert de le savoir :slight_smile:

Va falloir que je fasse plus gaffe :wink:

Hop décompilo powaah

rhaaa saleté de BB code

[Edité le 17/7/2002 par xentyr]

Hi hi hi sympa ce POST COuntO. J’ai toujours considéré que ce code, même si on est aux limites et qu’un développeur sensé ne prendra pas le risque d’écrire comme ça, était correct. Mais il semble qu’on soit, dans ce cas, hors norme… mhhh… je connais les problèmes de décision lorsqu’on est dans ce cas… m’enfin, j’aimerai bien trouver et voir de mes yeux que la révision ANSI précise ce cas comme indéfini. J’ai regardé dans ma version (je l’avais fait avant bien sûr :)), et je n’ai rien trouvé. Je ne dis pas que ce n’est pas vrai, hein :slight_smile:

Aller, je vais fouiller à nouveau… meeerrrde j’ai pas bcp de temps en ce moment ;), dommaghe c’est rigolo :cool:

bas nan, reste : c’est pas parce que c de la gestion que t’es pas un bon coder :
La gestion c important : c notre compte en banque, nos notes de frais (quoique la une petite erreur de temps en temps… ), nos factures, nos diplomes, tout plein de truc quoi :
donc il faut que les programmeur de gestion aussi viennent nous rejoindre dans la voie du code Simple et Sain.

(Et je connais la prog de gestion, et tien d’ailleurs, j’ai pas voulu gagner ma vie trops longtemps avec aussi :slight_smile: )

Je me sens petit joueur en assistant à de telles conversations… :slight_smile:

Je cours me rhabiller avec mes progs de gestion…

primo : relisez le premier poste : et avec le cerveau en MODE [JE MARCHE] :slight_smile:

secondo :

[quote]quelqu’un dit au dessus:

« le problème se situe autour de la condition : if( C>C++) et de l’utilisation des 2 caractères C et C++ dans une meme instruction »

bah justement c’est COMPLèTEMENT DéBILE comme problème.
ça ne pose AUCUN problème d’utiliser C et C++ dans une comparaison.

(0>0) donnera toujours FALSE comme réponse de test.
quand à
(0>1) ça donnera tout autant FALSE comme réponse de test.
(et pourtant on ne fera pas ce test puisque c++ veut dire qu’on incrémente après le test)[/quote]Le problem ici, est que dans la meme EXPRESSION : (C < C++) : tu a d’une part une comparaison sur C (C < « un truc ») et une incrementation de la meme variable (C++), ce qui pose un problem : L’evaluation de l’expression entraine la modification du resultat, et la modification du resultat entraine la modification de l’evaluation, qui entraine la …

donc, ANSI dit, pour simplifier que le resultat est indefinie, c tout.

( et j’ai tester avec les 2 : c++ et ++c )

[quote]1.ya vraiment pas besoin de mettre des arguments à un programme de ce genre
(argc, argv, …)[/quote]C’est toujours mieux : j’aime pas savoir qu’un compilo rajoute des trucs a mon code parceque j’ai pas eu la flemme de faire les choses tel qu’elles doivent etre faitent : en Dos, et sous winwin et sous pingouin Os, tout executable prends des parametres et retourne une valeur, et si tu declare :
void main(void), le compilo va implement int main(argc,argv,…) de toute facons (de l’interets de regarder le code genere : comme ca tu SAIS CE QU’IL FAIT, LE COMPILO)

[quote]2.si un compilateur donne TRUE comme résultat c’est qu’il compile pas du C ![/quote]Donc, a notre grand surprise, et aussi une peine enauuuurme, je viens d’aprendre que CodeWarrior mais aussi GCC 2952 et GCC 301, ainsi sans doute que les compilos Watcom, Intel et un certain nombrer d’autres, ne compile pas du C.
C dur.
Toute une carriere remise en jeu… :slight_smile:

[quote]3.Décompiler le programme en assembleur… Je vois pas l’intérêt.autant observer la lune avec un microscope électronique pour comprendre pourquoi quand on ouvre pas une porte, on ne passe pas à travers.[/quote]Pardon ?

Souviens toi, il y a tres tres longtemps, des gens ont creer le microoooprocesseur, et on le programmait en langage machines, puis d’autres gens ont creer l’assembleur, comme ca, c’etait plus simple avec des jolies mnemoniques, puis d’autres groupes de gens ont creer les languages de haut niveau, comme le c et le c++, mais dans leurs grandes mansuetude, pour que le bas peuple n’oublie pas l’existence du bon microooooprocesseur, ils ont rajouter l’options « compile mais n’assemble pas » dans leur compilateurs, pour que le peuple, dans sa soif de connaissance puisse : apprendre l’assembleur, trouver les bugs du compilateurs, comprendre comment ecrire son code C pour generer du code rapide et efficace, trouver la vrais voie du code, la voie du code simple et sain.
(enfin merde quoi, meme en JAVA on jette un coup d’oeil au bytecode de temps en temps :wink: )

[MODE VIEUX CON ON]
et tu vois, petit scarabe, si tu trouve que le code genere de ton dernier programme est aussi eloigne de toi que la lune l’est de l’amibe, tu as encore bien du chemin a parcourir sur la voie du code simple et sain, et tu es en train de sombrer dans la face obscure de la voie, le cote sombre, le coin des blaireau qui ont oublie que c le bo et bon Microoooprocesseur (remplacer par « JVM » pour ceux qui veullent, je suis pas sectaire.) qui execute leurs code simplement et sainement.

Pour faire une autres analogie, quand tu veux faire une quiche, tu achetes un roulo de pate toutes faites et puis tu fait ta quiche, mais de temps en temps il est aussi bon de se rappeler que faire de la pate briser c brisant.

C que tu n’ai pas encore assez avance sur la voie (le panno est un peu plus loin, la, a gauche), et que tu as encore beaucoup de choses a apprendre, comme lire les news groups ANSI, ou bien pauser les bonnes questions, ou encore ne pas flooder les forums des autres avec des MSG1 : ca veux rien dire, MSG2: ca veux rien dire, MSG3 : je comrpends pas donc ca veux rien dire.

et tu dois aussi apprends a ne rien croire que ce que tu n’as vue (ma mere me le disait encore hier : « Tu fait vraiment confience a ce blairo de CW, mais tu sais bien que cette pute reorganise l’asm inline, tu t’eloigne de la voie, mon petit (ma mamane est tres tendre avec moi) » : ne croit pas le compilateur, ne croit pas les libraires systems, ne croit pas le system, ne croit pas en toi, ne croit en rien, et suis la voie, la voie du code simple et sain.
[MODE VIEUX CON OFF]

Et pis j’aime pas qu’on m’emerde. :wink:

[quote]bah justement c’est COMPLèTEMENT DéBILE comme problème.
ça ne pose AUCUN problème d’utiliser C et C++ dans une comparaison.[/quote]La vraie question est : Est-ce que les spécifications ANSI prévoient ce cas ?

quote donnera toujours FALSE comme réponse de test.
quand à
(0>1) ça donnera tout autant FALSE comme réponse de test.
(et pourtant on ne fera pas ce test puisque c++ veut dire qu’on incrémente après le test)[/quote]On ne parle pas du sens mathématiques, voire logique ici, juste des specs !!!

[quote]1.ya vraiment pas besoin de mettre des arguments à un programme de ce genre
(argc, argv, …)[/quote]rhhhhooo, c’est petit :slight_smile:

[quote]2.si un compilateur donne TRUE comme résultat c’est qu’il compile pas du C ![/quote]Pourrais-tu nous le prouver s’il-te-plaît ? En effet, si c’est unspecified dans les spécifications du C, alors le compilateur fait ce qu’il veut !!! Il compilera toujours du C. Eh oui :slight_smile:

[quote]3.Décompiler le programme en assembleur… Je vois pas l’intérêt.[/quote]Efectivement, si tu n’en vois pas l’intérêt, on comprend mieux tes doutes… :wink:

[quote]autant observer la lune avec un microscope électronique pour comprendre pourquoi quand on ouvre pas une porte, on ne passe pas à travers.[/quote]humhum d’habitude j’observe la lune avec un téléscope :stuck_out_tongue: M’enfin, ça doit être encore une histoire de marteau-pilon et de mouches… :wink:

[quote]Je vois PAS de SENS. :casstet: :casstet: :casstet:[/quote]Valà, on est tous d’accord. Tu n’as pas l’air d’avoir compris où se situait le problème!
Si tu connais un site internet reproduisant les vraies spécifications ANSI C, n’hésite pas à faire tourner.

Il n’y a que l’ASM qui te permet de savoir ce que rend réellement ton compilo. Le problème, c’est que dans ce cas précis ça dépend du compilo. Donc est-ce une transgression des specs du C. Ca reste toujours à prouver !
Ainsi est-ce que la grammaire (la vraie, pas celle qu’on refait, hein) du C gère ça ? Parce que le problème peut se poser à plein de niveaux :
(liste non exhaustive)
if (C

heu, moi j’ai du mal avec le javascript alors quand on me parle de C, oulala…
enfin, ce que tu a marqué est quand même super interessant donc, hop, je garde. :wink:

Warnning, FAUX GEEK DETECTééééééééééé

Vu le CV du gars que tu critiques Hurlosaure, j’espère que t’es grave bon. Ho llalalala oui. Sinon ça va être drôle à regarder. Enfin à lire. :wink:

quelqu’un dit au dessus:

“le problème se situe autour de la condition : if( C>C++) et de l’utilisation des 2 caractères C et C++ dans une meme instruction”

bah justement c’est COMPLèTEMENT DéBILE comme problème.
ça ne pose AUCUN problème d’utiliser C et C++ dans une comparaison.

(0>0) donnera toujours FALSE comme réponse de test.
quand à
(0>1) ça donnera tout autant FALSE comme réponse de test.
(et pourtant on ne fera pas ce test puisque c++ veut dire qu’on incrémente après le test)

1.ya vraiment pas besoin de mettre des arguments à un programme de ce genre
(argc, argv, …)

2.si un compilateur donne TRUE comme résultat c’est qu’il compile pas du C !

3.Décompiler le programme en assembleur… Je vois pas l’intérêt.

autant observer la lune avec un microscope électronique pour comprendre pourquoi quand on ouvre pas une porte, on ne passe pas à travers.

Je vois PAS de SENS. :casstet: :casstet: :casstet:

Juste une p’tite remarque, peut être que je suis hors sujet…
Selon moi le test en lui même n’a pas de sens.
C = 0;
if ( C > C++) printf (“qqchose”); // En aucun cas le test ne peut être vrai. C ne peut être strictement supérieur à lui même, que l’incrémentation se fasse avant ou après le test …

[quote]Peut être que le problème est … simple ?

je vois vraiment pas la difficulté ![/quote]le problème se situe autour de la condition : if( C>C++) et de l’utilisation des 2 caractères C et C++ dans une meme instruction :

void main(){
int c=5;

printf("%d",c++);
}

affichera 5

void main(){
int c=5;

printf("%d",++c);
}

affichera 6

je sais pas si ça a un rapport, mais je crois qu’il y a un truc qui m’a échappé.

Peut être que le problème est … simple ?

je vois vraiment pas la difficulté !

on nous apprend dans les cours que ++c signifie que l’incrémentation se fait avant qu’on évalue la valeur.

et c++ signifie qu’on effectue l’incrémentation et qu’on évalue.

si un seul compilateur fait autre chose que ça !!! il compile PAS DU LANGAGE C, c’est autre chose.

[Edité le 16/7/2002 par hurlosaure]

Tiens une jeune fille esseullee






coooooooooooooool :smiley:

[quote]c’est quoi ce que t’as posté???
je comprend que dalle!!
c’est trop mathématiques!

arf , et dire que ça existe ce genre d’équation[/quote]et, pour ta culture personnel, c super pas mathematique, mais tretretre informatique :wink:

et p’tet un jours on pourra faire un post « apprends la programation » comme ca on se sentira moins seuls :slight_smile:

[Edité le 15/7/2002 par c0unt0]

waouuuu !

c’est quoi ce que t’as posté???
je comprend que dalle!!
c’est trop mathématiques! :smiley:

arf , et dire que ça existe ce genre d’équation :wink:

Sur la base du resultat a la question pause : c comme l’ecole des fans : ils ont tous gagne :smiley: le resultat est indertermine, donc chacun fait ce qu’il veux, maintenant au niveau du code genere, on peut pas vraiment juge, le code etant trops simple et le mode release etant souvent sur le principe :
[tiens je suis une appli console win32, j’va initialiser des trucs : code MS de toute facons]
[pof je pousse la stack et je bouge deux trois registres : code super simple (genre 3 instructions max)]
[ha la je fais mon taf/j’affiche ou pas la chaine (depends du compilo) : soit rien soit je pousse deux adresse sur la stack et j’appel printf]
[et hop je ressort et je nettoie derriere moi]

le seul truc c mention « special debile » a CW pour avoir continuer a executer le test meme s’il pouvais prevoir le resultat :wink:

Donc comme conclusion quel est le meilleur compilateur Win32 ?

merci, je garde ça dans un coin, c’est intéressant et ca peut toujours servir :wink: