Style de C particulièrement opaque

Bonjour, simple programmeur en C pour des développements modestes, j'ai trouvé en étudiant le source d'un programme de minimisation un style de programmation très étrange, avec des instructions quasiment absurdes comme:

Code:

---

1 2 3 4

double rw[10000],pf[10000]; double f[10],g[1000],x[1000],xl[1000],xu[1000],param[12]; ...... fonc(..,&*f,&*g,&*x,&*xl,&*xu,....)

---

et aussi

Code:

---

1 2 3

if (*g != *g) { ...... }

---

La raison de telles instructions syntaxiquement correctes me semble très obscure, et pourtant, l'insertion de tests sur l'expression (*g != *g) montre que le résultat n'est pas toujours faux.
Existe-t-il une explication de ce comportement?
Par ailleurs, le programme se compile et fonctionne correctement, mais son analyse est un défi.

if (*g != *g) Non c'est logique :mrgreen: :mrgreen:: comme il déférence des pointeurs tableaux, il compare la première case dudit tableau.
Mais comme ce sont des doubles, les comparaisons sont inexactes (je te laisse chercher comment tester 2 flottants)

Édit: mais c'est la même variable qu'on teste :oops:


Et &*f,&*g,&*x,&*xl,&*xu: il faudrait vérifier avec des %p :koi: :koi:, mais je dirais qu'il prend l'adresse de la première case des tableaux

Bonjour,

le test ( *g != *g ) peut être vrai! Si g pointe sur une valeur quiet NaN.
NaN a la particularité d'être différent de tout nombre y compris de lui-même!

Quant à &*f ou &f[0], comme f est un tableau cela désigne le début du tableau est a le type double*.
Alors que f, désigne aussi le début du tableau mais a le type double(*)[10].
En C, je ne vois pas l'intérêt de distinguer ces cas. En C++, cela peut servir lors de résolutions de template.

Merci pour la réponse, mais dans la comparaison en question, quel que soit l'élément pris, qui en l'occurrence est normalement le contenu de l'adresse mémoire g, on compare une chose à elle même car l'expression

Code:

---

*g

---

ne modifie pas le contenu de g, donc que

Code:

---

(*g != *g)

---

puisse être vraie me reste incompréhensible.
Quant à

Code:

---

&*x

---

, elle correspond effectivement à x, je me demandais seulement le pourquoi d'une telle expression, notamment si ce n'est pas une transcription "automatique" en C provenant d'un autre source ou d'un générateur de code?

Citation:

---

Envoyé par foetus

if (*g != *g) Non c'est logique :mrgreen: :mrgreen:: comme il déférence des pointeurs tableaux, il compare la première case dudit tableau.
Mais comme ce sont des doubles, les comparaisons sont inexactes (je te laisse chercher comment tester 2 flottants)


Et &*f,&*g,&*x,&*xl,&*xu: il faudrait vérifier avec des %p :koi: :koi:, mais je dirais qu'il prend l'adresse de la première case des tableaux

---

Bonjour,

En C, si x est un tableau, passer en argument x ou &x[0], c'est la même chose pour le compilateur, mais pas forcément pour le lecteur.
Si je vois un argument &x[0], je m'attends à ce que la fonction ne travaille qu'avec le premier élément du tableau et ignore les autres.
Si je vois un argument x, j'ai plus tendance à penser que la fonction ne va pas se contenter du premier élément.

&*x, par contre, je ne sais pas. Je pense que c'est une convention propre à l'auteur du code. Est-ce que la fonction ne prend en compte que le premier élément ? Si oui, alors &*x est utilisé comme une forme plus concise de &x[0]. Sinon, je ne sais pas.

Bonjour,

Désolé de ne pas répondre dans l'ordre...
Voici la routine qui contient le tets en question, avec mes ajouts:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

integer i304_(doublereal *g) { /* System generated locals */ integer ret_val;   ret_val = 0; fprintf(stdout,"########### DANS i304_1 : *g %x, g %p ###########\n",*g,g); fprintf(stdout,"########### DANS i304_2 : (*g != *g) %x ###########\n",(*g != *g)); if (*g != *g) {   ........

---

Le détail de mes sorties de test donne :

|#### ARGUMENTS APPEL I304_ E ####
|doublereal*g &l[1] : nan , 00a070a8, 10514600
|#### ARGUMENTS FIN ####

########### DANS i304_1 : *g 0, g fff80000 ###########
########### DANS i304_2 : (*g != *g) 1 ###########

Le résultat de la comparaison est effectivement vraie lorsque *g est affiché à nan du moins en format %e, en format %x il vaut 0.
J'ignorais les propriétés particulières de cette valeur nan (quand j'ai appris la programmation, elle n'existait pas. d'où des plantages pur et dur).
Est-ce une manière orthodoxe de coder ainsi ou aux bordures de la norme?
En tout cas merci pour cette information.

Citation:

---

Envoyé par dalfab

Bonjour,

le test ( *g != *g ) peut être vrai! Si g pointe sur une valeur quiet NaN.
NaN a la particularité d'être différent de tout nombre y compris de lui-même!

Quant à &*f ou &f[0], comme f est un tableau cela désigne le début du tableau est a le type double*.
Alors que f, désigne aussi le début du tableau mais a le type double(*)[10].
En C, je ne vois pas l'intérêt de distinguer ces cas. En C++, cela peut servir lors de résolutions de template.

---

Citation:

---

Envoyé par arsinuline

Est-ce une manière orthodoxe de coder ainsi ou aux bordures de la norme?

---

Tu as raison en disant que tester la même variable cela doit être vrai puisqu'il n'y a pas de modification :oops: :oops: (que ce soit une comparaison binaire ou flottante)

Sinon pour ta question, pourquoi ne pas envisager un test pour tester les NaN ? :koi:

D'après wiki NaN (<- lien), c'est dans la norme:

Citation:

---

Cela conduit même à ce que la comparaison « NaN==NaN » (« == » signifie « est-ce que ces valeurs sont égales ? ») donne la réponse « faux ». C'est la seule valeur ayant cette propriété (même l'infini, selon la norme IEEE 754, donne « vrai » pour la requête « Inf==Inf »).

---

Le fondement logique de cette norme semble être de dire que deux entités non définies ne peuvent être identiques, ce qui est discutable, elles sont donc différentes, mais en fait on a déplacé le problème, car syntaxiquement on compare une entité à elle même, un compilateur intelligent ne devrait pas laisser passer cela.
Il est probable que le confort apporté par la tolérance à l'erreur, qui consiste à traiter des entités mathématiquement non définies, conduit à des situations du type

Code:

---

a == a est faux si a=nan

---

.
Mais il est vrai que le bout de code que j'incrimine est très certainement le résultat d'un traducteur automatique Fortran -> C.


D'après wiki NaN (<- lien), c'est dans la norme:[/QUOTE]