Jump to content
Neo Force Order Resurrection
Dr_Windu

Tout Est Codable Ou Presque

Recommended Posts

si si, l'appel d'une fonction en C est séquentielle, donc pas d'indétermination pour un compilateur donné.

 

ps: d'ailleurs se fourbe fais les Incrémentation en premier, DIDJU, c'est pas ce que j'ai codé pourtant!!!

00403864 incl   0x1c(%esp)
00403868 incl   0x1c(%esp)
0040386C incl   0x1c(%esp)
00403870 mov	0x1c(%esp),%eax
00403874 mov	%eax,0xc(%esp)
00403878 mov	0x1c(%esp),%eax
0040387C mov	%eax,0x8(%esp)
00403880 mov	0x1c(%esp),%eax
00403884 mov	%eax,0x4(%esp)
00403888 movl   $0x476084,(%esp)
0040388F call   0x421110 <printf>

FOURBE, MECHANT COMPILATEUR, C'EST PAS COMME CA QUE TU DOIS FAIRE!!!

 

pps: j'arrive pas a croire que j'arrive a lire ce machin et que je le comprenne en plus, je suis horrible

ppps: d'ailleurs, on voi un joli mov d'une jolie adresse comme ca en dur dans la pile, heureusement que printf demande un const char*, sinon yaurais eu un segfault.

Share this post


Link to post

En tout cas ca rafraichit la mémoire tout ça ! Mais bon on sait tous que le C/C++ c'est dépassé maintenant hein ? :P

(On est dans la section délirium j'ai l'droit !)

Share this post


Link to post

ouais, c'est sur que les machines virtuelles c'est le bien, JVM toussa, Garbage collector. Tiens, ce serais drôle une informatique de bords codée en java (c'est surement pas temps réel ce truc en plus): "olol, tu peux pas freiner, je dois changer la musique avant"

 

PS: A noter, ce genre de blague sur le scheduler pas temps réel qui fait crasher une bagnole ca marche toujours bien en informatique industrielle.

Share this post


Link to post

L'embarqué c'est ASM ou à la rigueur C. Stoo.

 

Cela dit, si vous voulez programmer avec un GC et en haut niveau... faites du fonctionnel pur ! Tout récursif, zéro variables, zéro effet de bord.

Share this post


Link to post

si si, l'appel d'une fonction en C est séquentielle, donc pas d'indétermination pour un compilateur donné.

 

ps: d'ailleurs se fourbe fais les Incrémentation en premier, DIDJU, c'est pas ce que j'ai codé pourtant!!!

00403864 incl   0x1c(%esp)
00403868 incl   0x1c(%esp)
0040386C incl   0x1c(%esp)
00403870 mov	0x1c(%esp),%eax
00403874 mov	%eax,0xc(%esp)
00403878 mov	0x1c(%esp),%eax
0040387C mov	%eax,0x8(%esp)
00403880 mov	0x1c(%esp),%eax
00403884 mov	%eax,0x4(%esp)
00403888 movl   $0x476084,(%esp)
0040388F call   0x421110 <printf>

FOURBE, MECHANT COMPILATEUR, C'EST PAS COMME CA QUE TU DOIS FAIRE!!!

 

pps: j'arrive pas a croire que j'arrive a lire ce machin et que je le comprenne en plus, je suis horrible

ppps: d'ailleurs, on voi un joli mov d'une jolie adresse comme ca en dur dans la pile, heureusement que printf demande un const char*, sinon yaurais eu un segfault.

 

Quand il y a effet de bord, il y a aussi point de séquence. L'opérateur "virgule" est un point de séquence. Si j'ai :

 

int i = 0;
++i, ++i; // Ca marche, comportement déterminé. Le premier i++ est évalué. Ensuite le second.

 

Dans un appel de fonction, ce n'est pas l'opérateur "virgule" qui est appelé (donc pas de point de séquence), c'est juste un séparateur. De ce fait, il n'y a pas de comportement déterminé dans le cas de Doc (si on veut respecter la norme). On ne peut pas savoir quand est-ce que "i" sera incrémenté.

 

Si on force le compilateur à passer outre, il fait un peu ce qu'il veut et comme tu as pu le constaté, il a préféré évaluer toutes les incrémentations avant de push les valeurs.

 

De manière générale, je crois même que le compilateur va évaluer toutes les expressions avant de d'appeler une fonction. Si on a :

 

int i = 0;
f(i++);

 

La variable "i" sera incrémentée avant même que l'appel de f soit faite (avant l'intruction call et même si la valeur "0" a été passée à f). Pourquoi ? Tout simplement parce que l'appel d'une fonction constitue un point de séquence. Surpriiiiiiiiiise.

 

Après, pourquoi ce n'est pas fait entre deux push... ça changera rien dans les deux cas x)

Share this post


Link to post

L'embarqué c'est ASM ou à la rigueur C. Stoo.

 

Cela dit, si vous voulez programmer avec un GC et en haut niveau... faites du fonctionnel pur ! Tout récursif, zéro variables, zéro effet de bord.

 

Pour une application safe, il y a aussi l'Ada ^^

Share this post


Link to post

a noter: les anciennes versions de printfx86 contenaient un effets de bord si utilisée en ASM, elle ne restauraient pas la valeur de CX.

 

je ne sais pas pour les versions plus récente.

 

Lada? contre un baril de pétrole?

Share this post


Link to post

J'ai pas dormi de la nuit alors pas taper si je dis des conneries, mais sur le truc de RP ca donnerait pas quelque chose du genre :

 

a=16 b=3 ?

 

j'ai supposé que ca passait sous forme de pile, donc le --B se faisait en premier, le b++-- revient du coup a faire 3+1-1, ce qui donne a = 8 + 8 +3 -3 ou quelque chose dans le genre.

mais c'est tellement tordu que j'suis pas tres confiant dans ma réponse la :|

 

Edit :

 

comme j'ai un peu de temps a tuer la (chuis en cours) j'vais detailler un peu :

 

j'considere que ++a et --b sont effectué avant tout autres choses, donc avant d'entrer dans le reste du calcul on a a = 8 et b = 3

apres ca je suppose qu'on respecte les regles de priorité propres aux équations mathématiques (sinon ca serait le chaos), donc parenthese avant les additions/soustractions

ce qui donne :

 

a = a + (a + ((b-1)+1) - b )

 

on remplace par les valeurs :

 

a = 8 + (8 + ((3-1)+1) - 3)

 

on déroule et on tombe sur a = 16.

 

la par contre j'hésite, a priori les opérateurs sont considérés comme des fonctions, mais comme en Java tout est pointeur les variables devraient conservé les modifications. Donc je considere que b vaut toujours 3 meme apres l'equation.

d'ou a = 16 et b = 3.

 

bon apres c'est basé pas mal sur des supositions pas forcement tres fondés, donc si quelqu'un a testé... :D

Share this post


Link to post

tu ne peut pas faire b++-- en C. Parce que un opérateur n'est pas une Lvalue correcte.

 

Et puis ici, c'est (b++)--; ce qui corresspond a faire -- sur la valeur de b et non pas sur b.

Share this post


Link to post

Ben chuis pas certain hein, mais c'est du Java le code qu'il nous a donné la pas du C.

du coup je sais pas trop comment interagissent les parantheses pour le (b++)-- et je trouve pas grand chose sur le sujet (apparement personne n'est assez con pour faire ca)

 

par contre dans la meme idée j'ai trouvé ca :

 

http://www.theserver...thread_id=63624

 

pour les fainéants :

x+=x++ * x++ * x++

 

ce qui se résout, d'apres un commentaire :

 

"//this problem resolves to x+(x+2 * x+1* x)

This is operator precedence problem"

 

m'enfin si un jour j'suis rendu a faire ce genre de code, j'fais un ctrl+A suivi d'une delete et j'recommence tout <_<

 

Edit :

 

j'ai trouvé comment marche les a++ et ++a en Java, chuis toujours pas sur pour le (a++)-- mais j'me suis un peu trompé pour le reste apparement !

 

a+= (++a) + ((b++)--) - (--b ); a=7 b=4

 

a+= (8) + ((b++)--) - (--b ); a=8 b=4

a+= 8 + (4)-- - (--b ); a=8 b=5 (alors la c'est le truc bizarre, quand on a a++ le compilateur remplace le a part sa valeur AVANT d'appliquer le ++, et il applique avant quand on a --a !

a+= 8 + 3 - (--b ); a=8 b=5 (a priori le ((4)--) n'influence pas la valeur de b )

a+= 8 + 3 - 4; a=8 b=4

a+= 8 - 1; a=8 b=4

 

= >a = 15 b = 4

Share this post


Link to post

Ah ok merci, j'me sentirais moins con en allant me coucher ce soir :D

 

bon bah du coup RP shame on you ! pour nous donner des rébus a la con qu'on peut pas faire :(

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×