bonsoir,
dans le code ci dessous, qq1 pourrait - il m'expliquer la notation *p++ car je ne comprends pas (p est un pointeur de de chaine de caractères, on incrémente quoi alors, le pointeur ??? ) ?
merci

unsigned char buf[1024];

p = buf;

if( *p++ != 0 || *p++ != RSA_SIGN )
return 5;

while( *p != 0 )
{
if( p >= buf + siglen - 1 || *p != 0xFF )
return 5;
p++;
}
p++;
break;
}

on incrémente l'adresse mémoire visée par le pointeur

la première condition vérifie donc quoi ?
que le premier caractère de p n'est pas un 0 ou que ce n'est pas la constante désignée par RSA_SIGN ?

ca dépend si *p est incrémenté avant ou après la condition

il me semble qu'il y a une différence entre ++*p (je sais même pas si ca existe ) et *p++. Ah, ces codes écrits par des gens qui ne bossent certainement pas en équipe

au fait, je me suis trompé, *p++ incrémente la valeur inscrite dans la case mémoire référencée par le pointeur, pas la valeur du pointeur.

p++ est une post-incrémentation.
++p est une pré-incrémentation.

if( *p++ != 0 || *p++ != RSA_SIGN )
Ceci signifie que tu vérifies que p n'est pas 0, ni RSA_SIGN, puis tu l'incrémentes (condition vérifiée ou pas).

Par contre, si le code avait été :
if( ++*p != 0 || ++*p != RSA_SIGN )
La valeur de p aurait été incrémentée avant tout traitement, puis aurait eu les comparaisons.

Ps : merci les professeurs sadique qui pose des questions comme "que vaut p+++a ?"

Même si ce code est correcte, il est fortement déconseillé d'utiliser de tel expression qui sont difficile à lire. Par exemple, l'interprétation de Bunyan est fausse. Ce code est équivalent aux lignes qui suivent (et qui ne sont pas moins efficaces) :
v = *p;
p = p + 1;
if (v == 0)
{
w = *p;
p = p + 1;
}
if (v != 0 || w != RSA_SIGN)

donc ce n'est pas le même caractère qui est testé contre 0 et contre RSA_SIGN et p peux être incrémenté deux fois. Le code est correcte malgré tout car la norme indique que || doit évaluer ses arguments de gauche à droite et s'arrêter dès que l'un d'eux est non-nul (mais c'est quand même tout à fait illisible).

"if( ++*p != 0 || ++*p != RSA_SIGN ) "

Peut etre qu'il y a une exception que je ne connais pas. Mais dans mes souvenirs, si la meme variable est incrementer deux fois dans la meme ligne, le comportement obtenu n'est pas fixe par la norme du C. L'utiliser est donc fortement deconseille.

Erf, zut, désolé pour la mauvaise explication :/

Je m'amusais à lire ce topic.

Et je me dis que pour écrire des choses comme ça, les profs qui posent des questions aussi nazes ou les gens qui l'écrivent pour montrer qu'ils connaissent des détails obscures sont des gens qui ne vont pas très très bien.

Cela n'a aucun, mais alors aucun interêt de savoir ce que fait
p+++a.
Si je vois un jour quelqu'un me poser cette question, je fais de l'obfuscation sur le code de mon compilateur et je lui demande ce que fais telle fonction.
Ou alors je lui demande juste d'écrire un programme simple qui calcule des intégrales de Gauss. Et je vais bien rire.

J'ai vraiment l'impression que c'est un délire de complexe de supériorité (fréquent chez les informaticiens) que de vouloir prouver qu'ils peuvent écrire des choses aussi obscures et aussi laides, défiant alors tous les fondements de la qualité logiciel.

Beeerk !

il me semble lever une erreure
( *p++ != 0 || *p++ != RSA_SIGN )
quand les 2 conditions sont false, il doit valuer les 2.
Du coup p prends 2 incrémentations et on saute le 2eme charactere ?

Faut pas coder comme ca

A la relecture ca pique les yeux
un peu comme du langage SMS.

Pour ceux qui aime le code illisible, il existe l'ocaml

Ocaml du code illisible ?

Je ne devrais peut-être pas surenchérir sur un post trollesque, mais Ocaml (et toute la lignée des langages fonctionnels, dont Haskell, Lisp, Miranda...) sont des langages qui permettent d'exprimer succintement une solution de manière élégante, en laissant de côté les problèmes de bas niveau.

Jamais je n'ai vu un code C ou C++ ou Java plus élégant qu'un code Caml qui réalise la même chose.
Et pourtant je n'ai rien contre les langages impératifs ou orientés objet.

Il faut juste se rendre à l'évidence que la grande majorité des problèmes calculatoires d'aujourd'hui ne demandent pas d'être proche du matériel.
Des langages à haut niveau d'abstraction sont donc parfaitement adaptés dans ces cas là.
Je ne tiendrais pas forcement le même discours pour de l'analyse ou de la synthèse d'image, ou pour de l'embarqué, certes.

Mais tout le monde écrit-il un moteur 3D ou un système d'exploitation pour une archi très spéciale tous les jours ici ?

Je pense que bien utilisés, et utilisés quand il faut (ie sur des problèmes où ils sont adaptés), les langages fonctionnels permettent de faire les même choses de manière plus courte, plus fiable, et avec se bien meilleures possibilités d'évolution par la suite.

Bref, je veux bien ouvrir le débat fonctionnel VS autres, mais je ne pense pas que ce topic ci soit adapté.
Et si le débat est ouvert, je voudrais de vrais arguments.
Parce que du code C, C++, java, C# illisible, on en trouve à foison.

saleGauss : je suis avec toi. OCaml for Ever !

godrik : je pense que le cas particulier de cette expression est bien défini parce que la norme impose que l'évaluation des opérateur booléen soit paresseuse et se fasse de gauche à droite. Donc dans "( *p++ != 0 || *p++ != RSA_SIGN)" le deuxième p++ ne sera évalué que si le premier test échoue et donc l'ordre d'évaluation est bien défini (et lorsque le premier p++ est évalué la valeur de p est mise à jour aussi tôt). Malgré tout, c'est clair que moralement je suis contre de telle expression car elles sont à la limite du standard.

Oui, dnob dit juste, l'évaluation sera stoppée si la première condition est vraie.
Ainsi, en c++ on trouve beaucoup des notations du style :

if( ptr == NULL || ptr->hasError() )
{
...
}

En sachant que si ptr == NULL vaut vrai, l'autre partie, à savoir ptr->hasError() qui ferait tout cramer n'est pas pris en considération.

Même chose dans le cas du ET

if( ptr != NULL && ptr->isValid() )
{
...
}

C'est tout à fait safe comme code.

1. Ignorer chacharles31 chacharles31 Voir le profil de chacharles31
2. Posté le 28 mai 2010 à 17:32:11 Avertir un administrateur
3. il me semble lever une erreure

( *p++ != 0 || *p++ != RSA_SIGN )
quand les 2 conditions sont false, il doit valuer les 2.
Du coup p prends 2 incrémentations et on saute le 2eme charactere ?

Si la première est false, il y aura effectivement 2 incrémentations je dirai.
Mais comme ça a été dit, seuls les étudiants prétentieux écrivent ce genre de code, et c'est absolument pas accepté en entreprise.

Dans un souci de maintenabilité des grosses applications, on demande une lisibilité parfaite. Il est juste inimaginable que sur des opérations aussi simples on ait besoin d'y aller au debugger pour être sûr de ce qui se produit.

Je connais même des équipes où l'on impose d'écrire les tests de cette manière :

if( 15 == unEntier )

plutôt que

if( unEntier == 15 )

Pourquoi? Simplement pour éviter que par inadvertance quelqu'un écrive un jour

if( unEntier = 15 )

qui serait une affectation dont le résultat serait toujours true. Dans le cas ou la constante 15 est à gauche de l'opérateur, au moins ça compile pas donc aucun risque.

saleGauss j'ai pas dit que ocaml était pas élégant.

mais ca se relis pas facilement.
Plus l'ancien developpeur l'aura joué dans le plus pure ocaml style, plus il faudra se poser, respirer profondement par le nez en regardant les nuages pour comprendre ce qu'il a voulu faire.

T'as qu'a te dire que je suis une crepe en ocaml si ces précisions t'ont irrité

« mais ca se relis pas facilement. » ça dépend comment tu es "câblé".
Pour moi qui raisonne en terme d'ensembles et de fonctions (et pas en terme de pointeurs), le caml pur-style est on ne peut plus lisible.

Chacharles, excuses moi si mon post précédent t'a froissé, ce qui n'était pas du tout le but.

Je croyais que tu dénigrais totalement Ocaml par ton post précédent.

Maintenant, si tu nous dit que c'est juste que tu as du mal à lire du code Caml, je dirais juste que cela dépend des individus, et de qui a écris le code.
Je pense avoir une vision assez fonctionnelle naturellement, donc je n'ai pas trop ce problème.
Mais je te rejoins sur un point : Ocaml, comme tous les langages fonctionnels, invitent le programmeur a écrire de grosses expressions, d'applications d'applications d'applications de fonction à quelque chose.
Et parfois, si l'expression est vraiment trop grosse, il peut etre dur de s'y repérer.
Et cela peut etre encore plus dur si au passage il y a des applications partielles de fonctions, dures à repérer parfois.

Il y a un moment où il vaut mieux placer des "let ... in" plutôt que de se retrouver avec une enorme expression sur deux lignes.

Et pourtant, j'aime beaucoup l'esprit fonctionnel, mais des fois, à lire, si c'est pas bien commenté, ça peut "bloquer" dans le cadre de premières lectures.
Là où justement, un algo impératif ne sera pas totalement compris, mais où on aura une vague idée qui permettra de faire des bidouillages :D
En Ocaml, c'est soit on a vraiment compris (le code écrit par quelqu'un d'autre), soit on est incapable de rajouter des parenthèses.

C'est ça en fait que j'aime dans le style fonctionnel.
On ne peut pas tricher/bidouiller.
Parce que contrairement à du C/Java/C++, là ça ne compilera même pas...

Bref, désolé si tu avais cru que j'étais condescendant dans un post précédent.
J'essaye juste de faire découvrir le plus possible les langages fonctionnels, et quand j'ai lu ton post, j'avais l'impression de lire un détracteur total, mais qui ne donnait pas d'argument.

Bref, désolé.

« On ne peut pas tricher/bidouiller [en caml]. » il y a toujours Obj.magic